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1  Introduction 


Confidentiality  security  is  concerned  with  restricting  the  disclosure  of  in¬ 
formation  in  systems.  One  way  of  achieving  this  is  to  use  an  information 
flow  policy  which  defines  the  different  classes  of  information  (for  example, 
classified,  secret,  etc.)  that  can  exist  in  the  system  and  a  flow  relation  which 
describes  how  information  may  flow  between  these  classes.  System  entities 
(users,  processes,  files,  etc.)  are  considered  to  be  the  sources  and  sinks  of 
information,  and  each  is  bound  to  a  security  class  from  the  flow  policy.  This 
binding  is  interpreted  as:  if  entity  A  is  bound  to  class  a  then  A  may  source 
information  of  class  a  or  higher  and  may  sink  information  of  class  a  or  lower. 
A  system  is  considered  multilevel  secure  if  all  flows  between  entities  main¬ 
tain  the  flow  policy.  Note  that  there  are  special  cases  where  certain  entities, 
such  as  trusted  subjects,  are  allowed  violate  this  requirement  in  a  controlled 
manner. 

Traditionally  information  flow  policies  have  formed  lattices[8],  with  good 
reason  as  it  is  easy  to  build  state  based  enforcement  mechanisms.  However, 
it  may  be  desirable  to  enforce  non-transitive  information  flow  policies.  That 
is.  a  flow  policy  where  information  is  allowed  flow  from  class  a  to  class  6, 
and  from  b  to  class  c,  but  not  from  a  to  c.  An  example  of  such  a  policy 
is  reclassification:  there  are  three  classes  of  information,  secret,  classified, 
and  downgrade;  classified  is  allowed  flow  to  secret:  secret  is  allowed  flow 
to  downgrade,  and  downgrade  is  allowed  flow  to  classified,  but  secret  is 
not  allowed  flow  (directly)  to  classified.  A  (trusted)  security  officer,  cleared 
to  downgrade,  may  read  secrets  and  reclassify  as  downgraded  information, 
which  may  flow  to  classified.  Further  examples  of  reflexive  flow  policies  will 
be  given  in  in  this  report. 

Another  desirable  generalisation  for  flow  policies  concerns  the  consis¬ 
tency  of  the  join  operator  (the  lowest  upper  bound).  Traditionally,  if  in¬ 
formation  may  flow  from  a  to  c  and  from  b  to  c,  then  the  join  of  infor¬ 
mation  of  class  a  and  6  may  flow  to  c.  If  this  assumption  is  removed,  we 
have  a  means  of  describing  aggregation  flow  exceptions:  a  user  of  class  c 
is  allowed  to  sink  information  of  class  a  or  class  6,  but  not  their  aggre¬ 
gate.  That  real  aggregation  policies  exist,  is  demonstrated  by  Brewer  and 
Nash  in  their  popular  Chinese  Wall  paper[6],  and  supported  with  further 
examples  by  Meadows[20j.  Many  models  for  aggregation  policies  have  been 
proposed[6,16,19,12j.  We  seek  a  unified  definition  of  an  information  flow 
policy  that  includes  aggregation  properties. 

Separation  of  Duty  rules  are  normally  associated  with  integrity  policies 
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and  models[7,15,21].  For  example,  a  cheque  must  be  proposed  by  a  manager, 
and  cleared  by  an  accountant,  or  vice-versa,  before  it  can  be  written.  How¬ 
ever,  separation  rules  can  also  apply  to  information  flow  (confidentiality) 
policies.  For  example,  a  user  of  a  dial-up  database  may  only  view  database 
information  if  it  is  accompanied  by  charges  information.  This  type  of  sepa¬ 
ration  flow  policy  can  be  thought  of  as  dual  of  an  aggregation  policy:  only 
the  aggregate  may  flow,  not  the  individual  classes. 

This  report  proposes  a  single  structure  that  can  be  used  to  describe  infor¬ 
mation  flow  policies  that  may  have  transitivity,  aggregation  and  separation 
exceptions;  a  high  water  mark  mechanism  is  developed  for  enforcing  these 
policies. 

Section  3  examines  the  traditional  notion  of  an  information  flow  policy. 
Section  4  proposes  a  structure,  a  conglomerate  relation,  that  can  be  used 
to  describe  our  general  information  flow  policies.  Relations  and  operators 
over  flow  policies  are  developed  that  allow  flow  policies  to  be  compared, 
composed  and  abstracted.  We  use  the  Z  notation[23]  as  a  convenient  syntax 
for  flow  policies. 

Section  5  introduces  how  conglomerate  relations  can  be  used  to  capture 
aggregation  and  separation  exceptions  in  systems  and  in  information  flow 
policies,  and  defines,  the  abstract  requirements  for  a  secure  system. 

Section  6  shows  how  an  arbitrary  flow  policy  with  no  separation  (of  duty) 
exceptions  can  be  enforced  using  the  high  water  mark  mechanism  proposed 
in  [11].  With  a  high  water  mark  mechanism,  each  system  entity  is  bound  to 
a  class  that  represents  the  join  of  all  classes  of  information  it  has  sunk  to 
date.  Thus  as  a  system  progresses,  high  water  marks  rise.  Traditional  high 
water  marks  rise  to  a  single  limit [26],  in  our  model  there  is  a  set  of  possible 
limits.  The  policies  that  can  be  enforced  by  this  model  include  quasi-ordered 
policies,  and  reflexive  policies.  We  show  how  the  mechanisms  simplify  for 
these  cases  to:  the  traditional  lattice  flow  model[8]  with  static  binding  for 
quasi  ordered  policies;  the  interval  confinement  model[10]  for  reflexive  flow 
policies.  The  interval  confinement  model  can  be  viewed  as  a  generalisation 
of  models  that  associate  an  interval  of  classes  with  system  entities,  such  as 
partially  trusted  subjects[3,22],  and  high  water  marks  with  limits[26].  This 
leads  us  to  the  conclusion  that  we  can  classify  the  type  of  confidentiality 
policy  enforced  by  these  systems  as  reflexive.  Section  7  gives  examples  of 
reflexive  and  aggregation  flow  policies. 

Section  8  develops  an  alternative  high  water  mark  model  that  can  en¬ 
force  any  separation  and/or  aggregation  information  flow  policy.  As  before, 
every  entity  has  a  high  water  mark  that  may  rise  according  to  the  informa- 


tion  it  sinks.  However,  to  implement  separation,  water  marks  may  not  rise 
linearly — certain  class  combinations  may  be  invalid,  representing  separation 
exceptions.  Section  9  gives  examples  of  separation  flow  policies. 

Section  10  considers  the  relationship  between  separation  and  aggregation 
policies,  and  r,hows  how  complementing  one  can  give  the  other. 

The  structure  used  to  describe  an  information  flow  policy  can  also  be 
used  to  describe  an  integrity  policy.  Section  11  investigates  the  possibility 
of  using  conglomerate  relations  to  describe  integrity  policies. 

Section  12  contains  a  summary  and  discussion  of  the  work  described  in 
this  report.  The  appendix  contains  all  the  necessary  proofs  of  properties 
proposed.  The  Z  notation[23]  is  used  throughout  this  report. 
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2  Lattices 


Lattice  structures  will  be  used  in  this  Daper  to  describe  information  flow 
policies.  This  section  gives  a  Z  formulation  of  their  structure. 

The  set  of  all  partially  ordered  sets  is 

posefs[A'}  ==  {P  :  X  ~  A'|id  P  C  P  A 

Pi  P"1  =  id  P  A 

P%P=  P) 

A  partially  ordered  set  is  reflexive,  antisymmetric  and  transitive.  Given 
poset  P ,  then  a  >-*  b  £  P  means  that  a  is  less  than  or  equal  to  6  in  P,  (a  is 
dominated  by  b  in  P). 

Given  a  poset  P ,  then  an  element  a  of  this  set  will  have  a  set  of  upper 
bounds  (everything  that  dominates  it  in  P)  given  by  u-bounds  P  a,  and  a 
set  of  lower  bounds  given  by  l-bounds  P  a. 


rw  . 

u-bound_, 

l-bound_  :  pose/s[A'j  —  (A'  —  "PA') 

V  P  :  pose?s[.Y]  • 

u-boundP  =  {a  :  A'|o  6  dom  P  •  a  —  ran({a}  <3  P)} 
1-boundP  =  {a  :  A'|a  6  dom  P  •  a  *—  dom(P  C>  fa})} 


Functions  v-bound  and  l-bound  can  be  generalised  to  give  the  upper  and 
lower  bounds  that  are  common  to  a  set  of  elements  of  a  poset: 

=  [A']  - 

U- bound_, 

L-bound_  :  posetsf.Y]  —  (PA'  —  PA') 

V  P  :  pose/s[A'j  # 

U-boundP  =  {A  :  V\X\A  C  dom  P  •  A  *-»  nu*boundP(]/l[)} 
L-boundP  =  {A  :  V\X\A  C  dom  P  •  A  •->  f|  1-bound PQ^i[)} 


We  can  now  define  what  a  lattice  is.  A  lattice  is  a  partially  ordered 
set  such  that  every  set  of  elements  have  a  unique  upper  bound  that  forms 
a  lower  bound  on  all  other  upper  bounds  on  the  group  of  elements:  and  a 
unique  lower  bound  that  forms  an  upper  bound  on  all  other  lower  bounds 


on  the  group  of  elements. 


lattice[X]  =  = 

{P  :  posets[A']| 

V  A  :  VX  •  A  C  dom  P  => 

#(U-boundP  A)  D  (L-boundP(U-boundP  A))  =  1  A 
#(L-boundP  A)  n  (TJ-bo  undP(L-boundP  A ))  =  1} 

A  lowest  upper  bound  operator  (lub)  can  be  defined  on  a  lattice  such 
that  it  returns  the  lowest  upper  bound  of  a  non-empty  set  of  elements. 

r  [A’] . . 

0  _  :  lattice[X]  -  VX  h*  X 

V  L  :  lcftice[X]  * 

01=  {A  :  V\X\  a  :  A| 

(U-boundP  .4)  fl  (L-boundP  (U-boundP  .4))  =  {o} 

•  A  •—  a) 


A  binary  version  of  this  operator  can  also  ’»  e  defined  where  air  b  =  0{a.  b}. 

Given  some  set  of  elements  from  a  lattice,  the  maximums  on  this  set.  is 
the  sot  of  components  from  this  set  such  that  there  is  no  other  component 
in  the  set  that  dominates  these  maximums.  Note  that  if  the  lattice  is  total 
(i.e..  every  element  either  dominates  or  is  dominated  by.  every  other  element) 
then  there  is  just  one  maximum.  There  is  a  similar  definition  for  minimums. 

r  [A] - 

maxs_  :  lottic t[A']  — •  PA'  —  PA 
V  L  :  /flt/ice[A’]  • 

maxs  L  =  {A.  B  :  PA| B  C  A  A  .4  C  doni( L  t>  B)  A 
ran(  P<  L)  n  .4  =  B  •  .4  •—  B] 


A  powerset  lattice  of  a  set  of  elements  is  a  lattice  with  components  drawn 
from  the  powerset  of  the  elements;  a  partial  ordering  defined  by  subset,  and 
bound  operators  defined  by  union  and  intersection. 

r  [*1  — 

Vc _  :  PA  -  lattice[VX] 

V  A  :  PA'  • 

VCA  =  {B,C  :  PA'|C  €  VA  A  B  C  C  •  B  -  C} 


Wa 


A  powerset  lattice  >■  distributive,  i.e.,  its  bound  operators  distribute  over 
one  another,  and  complementable,  i.e.,  every  component  has  a  complement. 
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3  Secure  Information  Flow 


An  information  flow  policy  can  be  thought  of  as  defining  the  different  classes 
or  kinds  of  information  that  can  exist  in  a  system  and  how  they  may  prop¬ 
agate.  An  example  of  this  is  the  military  flow  policy  which  defines  a  set  of 
information  flow  classes  that  represent  the  sensitivity  of  information  in  the 
system,  and  an  ordering  relation  that  describes  relative  sensitivity.  Let  us 
introduce  the  set  of  information  classes  as  the  basic  type 

[c/asses] 

Rather  than  thinking  of  information  classes  as  just  security  classes  (as 
in  the  traditional  sense),  they  can  be  thought  of  as  a  way  of  associating 
a  simple  representation  of  meaning  with  information  in  the  system.  We 
shall  see  later  how  the  information  itself  is  represented  in  the  system.  For 
the  moment,  we  impose  the  traditional  restrictions^]  on  a  policy,  in  that  it 
should  form  a  lattice.  For  a  given  flow  policy,  P  6  lattice[classes ],  if  a  >—  b 
is  a  maplet  of  P.  then  it  means  that  information  of  class  a  is  permitted  to 
flow  to  class  6. 

To  apply  a  flow  policy  to  a  system  we  must,  in  some  way.  relate  the 
information  in  the  system  to  the  security  classes  of  the  policy.  We  chose  to 
do  this  by  viewing  the  system  in  terms  of  system  entities  and  the  informa¬ 
tion  flows  between  these  entities.  The  entities  of  a  system  are  the  sources 
and  sinks  of  information  of  interest  in  the  system.  They  might  correspond 
to  subjects  and  objects  such  as  those  in  [2],  or  the  more  abstract  system 
interfaces  of  [13].  Introduce  the  set  of  all  such  entities  as  the  basic  type 

[ents] 

The  functionality  of  a  system  will  be  abstracted  to  just  flows  between  these 
entities.  For  the  moment  we  will  not  concern  ourselves  with  semantics  for 
information  flow,  except  that  it  is  a  relation  between  entities.  Define  the  set 
of  all  possible  abstracted  systems  to  be 

systems  :  Vents  <—  ents 

systems  =  {5  :  ents  — -  ents |  id  5  C  5} 

If  5  €  systems  is  a  particular  abstract  system,  then  e  i —  /  6  5  means 
that  information  can  flow  from  entity  c  to  entity  /  over  the  system  5.  The 
only  requirement  we  will  place  is  that  information  flow  should  be  at  least 
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reflexive:  information  can  always  flow  from  an  entity  to  itself.  Note  that 
our  characterisation  of  information  flow  is  over  the  lifetime  of  the  system; 
we  wrill  show  later  how  a  flow  semantics  might  be  given  in  terms  of  states 
and  state  transitions. 

The  relationship  between  a  system  and  a  flow  policy  can  be  established 
by  binding  each  entity  to  an  information  flow  class  from  the  policy.  The 
class  of  each  entity  represents  the  class  of  information  that  the  entity  is 
allowed  to  sink  and  source.  The  system  is  regarded  as  secure  so  long  as  the 
multilevel  security  requirement  is  maintained,  i.e., 

if  information  flows  from  class  a  to  class  b  in  a  system  implies, 
that  must  hold  in  the  policy. 

Thus  we  define  a  secure  system  by 

_ Secure-System _ 

5  :  systems 
P  :  lattice[classes } 

3-  :  ents  -*•  classes 

dom/3_  =  (JdomS 
ran  3-  C  (J  dom  P 
V  e,/  :  ents  • 

e~feS=>de>-3f£P 


The  schema  states  that  a  system  5  is  secure  by  flow  policy  P ,  given  the 
entity  binding  function  3 .  if  every  flow  between  entities  in  the  system  is 
allowed  by  the  flow  policy.  The  other  restrictions  ensure  that  every  entity  is 
assigned  an  information  class  from  the  policy.  Entity  confinement  is  partial 
as  it  only  maps  entities  of  the  system  to  information  classes. 

It  is  attractive  to  use  lattice  based  information  flow  policies,  as  they 
lead  to  simple  flow  control  mechanisms[8]  that  are  inductively  defined  over 
secure  states  and  secure  transitions.  An  example  of  this  is  the  star  property 
and  ss-condition[2]  (under  strong  tranquillity);  the  tranquil  Bell  LaPadula 
model  can  be  thought  of  as  an  ‘unwinding’  of  our  abstract  notion  of  a  secure 
system. 

In  [9]  Denning  shows  how  an  arbitrary  reflexive  and  transitive  (quasi 
ordered)  ordered  set  can  be  transformed  into  a  lattice.  This  allows  us  to 
weaken  our  requirement  that  a  flow  policy  should  form  a  lattice,  to  one 
requiring  that  it  form  a  quoset.  Further  weakenings  of  these  requirements 
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can  be  made.  However  as  we  shall  see  throughout  this  report,  dynamic 
binding  mechanisms  are  needed  to  enforce  these  more  general  policies.  In 
[10],  a  method  for  enforcing  non-transitive  flow  policies  is  proposed.  This 
approach  also  results  in  simple  inductive  requirements  for  secure  states  and 
secure  transitions  which  result  in  an  implementation  mechanism  that  is  not 
unlike  a  high  water  mark  mechanism[25].  Furthermore,  non-transitive  in¬ 
formation  flow  policies  are  useful,  and  examples  are  given  in  [10,12]. 

Flow  policies,  whether  transitive[8]  or  not[10],  are  assumed  to  have  a 
consistent  class  combination  operator  ©  (giving  a  lowest  upper  bound  on 
lattice  classes),  where  if  information  of  class  a  flow  to  class  c  and  infor¬ 
mation  of  class  b  can  flow  to  c,  then  their  agg  .gate  a  ©  b  should  also  be 
allowed  flow  to  c.  This  initially  seems  reasonable — a  person  who  is  allowed 
read  access  to  one  file  or  another  should  also  be  allowed  read  both — and  it 
contributes  to  the  simple  flow  control  mechanisms.  However,  in  [6,16,19,12], 
confidentiality  policies  are  described,  whose  essence  is  that  class  combina¬ 
tion  does  not  form  an  upper  bound  operation;  a  consultant  is  allowed  read 
information  about  bank  A  or  bank  B,  but  for  conflict  of  interest  reasons,  not 
both[6].  Therefore,  we  propose  to  drop  the  requirement  that  an  information 
flow  policy  should  have  consistent  class  combination  operator  (i.e.,  lowest 
upper  bound  operator).  However  to  do  this,  it  is  no  longer  sufficient  to  rep¬ 
resent  an  information  flow  policy  as  allowable  flows  between  single  classes. 
We  need  a  new  structure  for  a  flow  policy  in  which  we  enumerate  not  only 
flows  between  classes,  but  also  flows  between  groups  of  classes. 
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4  A  Theory  of  Conglomerates 

In  this  section  we  will  describe  a  structure  that  will  be  used  to  describe 
information  flow  policies.  The  structure,  a  conglomerate  relation,  will  be 
defined  generically  as  it  will  also  be  used  to  describe  information  flows  in 
systems. 

When  we  use  a  simple  relation  to  describe  a  flow  policy  there  is  an 
implicit  assumption  that  if  a  may  flow  to  c  and  b  may  flow  to  c  then  the 
join  of  information  of  classes  a  and  b  may  also  flow  to  class  c.  To  remove  this 
assumption,  we  will  need  to  enumerate  whether  information  formed  from  the 
combination  of  a  and  b  can  flow  to  c.  Thus  the  information  flow  relation  will 
be  a  relation  of  type  ( Vclasses )  —  classes.  This  relation  describes  whether 
a  conglomerate  of  information  classes  (i.e.,  information  drawn  from  a  set  of 
classes),  may  flow  to  some  class. 

Define  the  set  of  valid  conglomerate  relations  to  be 


[J] -  - - 

71  :  V{VX  ~  X ) 

71  =  {P  :  VX  -  A' | 

V  a  :  A'  •  o  €  U  dom  P  u  ran  P  => 
fjdom  P  O  {a}  =  {o}} 


For  some  conglomerate  relation  P  :  7J[A'],  then  A  a  G  P  means  that 
the  conglomerate  of  elements  A  is  dominated  by  a  in  P.  This  is  akin  to 
saying  that  the  ‘join"  of  elements  of  A  is  dominated  by  a.  We  can  use 
this  structure  to  capture  relations  that  do  not  have  consistent  bounds.  For 
example,  we  may  have  maplets  {a,c}  h-  c  and  {b,  c}  >—  c.  but  not  have 
{a,6,c}  ►—  c.  The  constraint  on  the  set  7v[A']  is  such  that  an  element  is 
always  dominated  by  itself,  regardless  of  what  conglomerate  may  be  involved 
(a  form  of  reflexivitv).  We  shall  see  later  when  we  consider  the  set  7v[c/osses] 
that  these  are  reasonable  restrictions  to  make  for  flow  policies. 

A  conglomerate  relation  from  7S[A']  is  defined  over  a  subset  of  its  base 
type  X .  Define  the  alphabet  of  conglomerate  relation  to  be  this  set.  Since 
we  have  for  any  P  €  71  [A'] 

ran  P  =  |J  dom  P 

the  alphabet  of  P  is  simply  ran  P ,  and  thus. 
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F=  ]  ====== 

Q_  :  H[X\  -*  vx 


Some  useful  definitions  on  the  set  of  conglomerate  relations  are 

=  [A']  -  . .  .  . 

T_, 

-L_  :  VX  -  H[ X] 

V  C : VX  • 

T C  =  {a  :  A'ja  €  C  •  {a}  *-»  a} 

JL.C  =  {.4  :  PA ;  fl  :  A  [  <2  6  4  A  ,4U  C  C  •  .4  i--  o} 


Relation  T  A  gives  the  smallest  possible  conglomerate  relation  for  an  alpha¬ 
bet  A,  and  ±A  the  largest.  Enumerating  all  possible  relations  can  be  rather 
tedious,  so  the  operator  should  be  used  when  possible 

F=  1  ■ . ■■■■= . .  . 


_  :  VX  x  X  —  7i[A'] 

V  .4  :  VX;  a  :  A'  • 

A  ^  a  =  T.4  U  {A'  :  VX\ A'  C  A  •  A'  U  {a}  —  a} 
A'— *  a  =  (T4u{fl))U{.4U{a)  •—  a } 


Example  1  As  already  seen,  we  can  use  conglomerate  relations  to  describe 
relations  that  do  not  posses  consistent  upper  bound  operations.  Consider  a 
conglomerate  relation  R  with  alphabet  {a,6,c}  and  maplets: 

{a}  •—  a  {6}  ►->  b  {c}  *-»  c 
{a, c}  •—  c  {6.  c}  i—  c 

or  defined  in  shorthand  as, 

R  =  ({a}  c)  U  ( { 6}  c) 

This  relation  does  not  have  a  consistent  upper  bound  (join)  on  elements  a 
and  6:  element  a  is  dominated  by  c,  element  b  is  dominated  by  c,  but  the 
conglomerate  {a,6,c}  (which  represents  their  join)  is  not  dominated  by  c. 
A 
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A  conglomerate  relation  P  :  7v[A']  contains  an  aggregation  exception  if 
there  are  conglomerates  A,  B  :  VX ,  and  a  :  X,  such  that 

A^aE.Pf\B*->a£PhAUB>-*agP 

In  the  last  example,  relation  R  contained  an  aggregation  exception.  A  dual 
to  an  aggregation  exception  is  a  separation  exception ,  where  there  are  con¬ 
glomerates  A,  B  :  VX ,  and  a  :  X  such  that 

A\jB*->aePA(A~a#P\/B~agP) 

4.1  A  Framework  of  Conglomerate  Relations 

In  this  section  we  will  show  that  the  set  of  conglomerate  relations  7l[X] 
forms  a  lattice.  Appendix  A  contains  all  the  appropriate  proofs. 

The  abstraction  operator  allows  us  to  hide  certain  elements  of  a  conglom¬ 
erate  relation.  If  P  is  a  conglomerate  relation  and  C  some  set  of  elements, 
then  P&C  gives  P  abstracted  to  elements  of  C.  This  can  be  thought  of  as 
viewing  P  though  the  ‘eyes’  of  the  window  C. 


f=  ['^  ] . . = 

:  n[X]  x  VX  -  7l[X) 


VP:ft[A']:  C  :  VX  • 

P<sC  =  {.4  :  VX  •  A  (1  C  ~  .4}  |  (P  >  C) 


If  C  *—  a  appears  in  relation  P.  then  CDqP  •—  a  appears  in  P&C  iff  a  £  C. 
The  abstraction  operator  always  returns  a  valid  conglomerate  policy.  Some 
laws  for  abstraction  are:  given  P ,  Q  :  7J[A'];  B.  C  :  V A',  then 


q(P®C)  = 
P§{}  = 

PQaP  = 
(P@B)@C  = 
PC  Q  A  B  C  C  => 


oPnC 

{} 

P 

F@(5  n  C) 

C  Q<aC 


Example  2  A  conglomerate  relation  has  alphabet  {a,  6,  mid }  and  is  defined 
as 


R  =  {a}  mid  U  {a,  mid)  b 


15 


(a  total  ordering  with  a  <  mid  <  6).  If  element  mid  is  hidden  we  get, 
R@{a,  6}  =  {a}  b 

(a  simple  ordering  a  <  b).  If  R  =  {a}  mid  U  {mid}  b  (i.e.,  non¬ 
transitive),  then  R@{a,  6}  =  T {a,  b}.  A 

Example  3  A  conglomerate  policy  with  alphabet  {a,  6,c}  is  defined  as 

R  =  {a,  6}  c 

=  T{a,6,c}u{{a,6,c}~  c} 

Note  how  only  the  conglomerate  of  a  and  b  can  be  dominated  by  c.  If  R  is 
abstracted  to  {a,  c}  we  get 

R@{a,  c}  =  {a}  c 

reflecting  that  when  R  is  viewed  though  a  window  {o,  c),  the  viewer  cannot 
see  how  b  can  affect  the  relation,  and  thus  does  not  know  when  maplet 
{a,c}  i — '  c  is  observed  that  it  was  a’s  join  with  b  that  made  it  possible.  A 

There  is  a  partial  ordering  relation  C  defined  between  conglomerate  re¬ 
lations.  If  P  C  Q  then  we  say  that  <5  is  more  restrictive  than  P,  in  that 
any  maplet  that  is  not  allowed  by  P  will  also  not  be  allowed  by  Q.  Note 
however,  that  Q  may  introduce  additional  elements. 


rI*l 

_  C  _  :  n{ X]  -  £[.Y] 

V  P,Q  :  ft[A’]  • 

PQQ& 

aP  C  aQ  A  Q(QqP  C  P 


Conglomerate  restrictiveness  and  abstraction  are  monotonic  with  respect  to 
each  other:  given  P,  Q  :  TZ[X}\  B,  C  :  VX ,  then 

BCCAPCQ=>  P&B  C  Q@C 

Restrictiveness  is  rather  like  a  combination  of  refinement  and  concealment[14] 
If  P  C  Q,  we  use  abstraction  (concealment)  to  hide  any  new  elements  in¬ 
troduced  by  Q,  and  then  check  that  the  result  is  a  subset  (refinement)  of 
P. 


16 


The  set  of  conglomerate  relations  T^A']  forms  a  lattice  with  lowest  upper 
and  greatest  lower  bound  operators  defined  by  LI  and  n  respectively. 


r[X) -  -  - — 

_u_, 

_n_:  n[x]  x  n[x]  -»  tz[x] 

VP,Q:1l[X}» 

P  U  Q  —  {A  :  VX ;  a:  Jf|ylU{a}CQPLlQ(3A 
(fl£a£j^Xna£jwoe  Q)  A 
(a  €  aP  =>  A  n  aP  a  €  P)} 

PH  Q  =  P@(aPnaQ)  U  Q@(aPDaQ) 


Note  that  for  P ,  Q  :  72[A']  we  have, 

a{P  \J  Q)  ~  aP  U  qQ 
q(P  n  Q)  =  qPDqQ 

Example  4  Define  the  relations 

P  ={o}^6  Q  =  {6}  -v,  a 
R  —  {6,c}~»  a  S  —  c 

The  join  of  P  and  Q  must  preserve  the  restrictions  of  both  policies,  and  thus 
P  U  Q  =  {a,  6},  i.e.,  no  flows  are  possible  except  reflexivity.  In  the  join, 

P  l\  R  =  T{a,  b,  c}  U  {c}  a 

the  maplet  {o.6,c}  • —  a  is  not  included,  since  it  introduces  a  conflict  with 
{a,  6}  *-f  6  e  P,  when  viewed  through  the  alphabet  of  P.  If  one  policy 
introduces  new  classes,  then  any  flow  involving  those  classes  are  valid,  as 
long  as  they  do  not  violate  the  original  policy.  Thus 

P  U  5  =  {a}-^  6u{a,6}^  cU{c}^  a 


A 

The  set  of  all  conglomerate  relations  with  the  same  alphabet  A  forms  an 
algebra  that  is  a  sublattice  of  Tl[X]  with  restrictiveness  defined  by  superset; 
LI  defined  by  intersection;  n  defined  by  union,  and  universal  upper  and  lower 
bounds  defined  by  T A  and  1A,  respectively.  Since  it  forms  an  algebra,  each 
conglomerate  relation  P  has  a  complement  defined  by  P. 
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r[X)~ 

_  :  n{X]  -*  n[X) 

V  P  :K[X]  • 

P  =  TaP  U  (LaP  -  P) 


Since  P  is  complement  operator,  we  have 

PUP  =  TaP 
PnP  =  LaP 

4.2  Classes  of  Conglomerate  Relations 

The  set  of  conglomerate  relations  that  do  not  possess  any  separation  excep¬ 
tions  is  defined  as 

72_S[A]==  {R  :TZ[X]\'iA,A':VX\  a  :  X  • 

A  U  A' a  e  R  =► 

{ 4  •—  o,  4'  i — -  a}  C 

We  call  72 -s[-Y]  the  set  of  aggregation  relations.  Conglomerate  join  is  closed 
over  aggregation  relations. 

The  set  of  conglomerate  relation  that  do  not  posses  any  aggregation 
exceptions  is 

Tl-A[X)  ==  { R  :  72[A']|Vj4. 4'  :  VX\  a  :  X  • 

{4  h-  a.  A'  ~  o}  C  R  => 

A  U  A'  —  a  6  /?} 

We  call  this  set  the  set  of  separation  relations.  Conglomerate  join  is  closed 
over  separation  relations. 

The  set  of  conglomerate  relations  that  posses  neither  aggregation  nor 
separation  exceptions  is 

72o[A']==72_y4[A']n72_s[A'] 

We  call  this  set  the  set  of  reflexive  relations.  It  is  easy  to  show  that  any 
relation  R  G  72<>[Ar]  can  be  represented  by  a  simple  reflexive  relation  A'  <— 
X.  Conglomerate  join  is  closed  over  reflexive  conglomerate  relations,  and  is 
equivalent  to  the  definition  of  join  for  reflexive  relations  defined  in  [10] 
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Finally,  the  set  of  quasi  ordered  conglomerate  relations  (reflexive,  tran¬ 
sitive,  and  no  bound  exceptions)  can  be  defined  as 

guoset[A']  ==  {R  :  71©|V a,b,c  :  X  • 

{a}~>  6  U  {6}  c  C  R  => 

{a}  c  C  R) 

4.3  Inconsistent  Lower  Bounds 

The  definition  of  a  conglomerate  relation  cannot  capture  relations  that  have 
inconsistent  lower  bounds:  if  a  is  dominated  by  b  and  a  is  dominated  by 
c,  then  it  implicitly  implies  that  a  is  dominated  by  b  and  c.  If  we  wish 
to  capture  relations  that  have  inconsistent  lower  bounds  it  is  necessary  to 
enumerate  lower  bounds  as  conglomerates,  not  single  components.  Thus  a 
conglomerate  relation  would  be  of  the  form  VX  ~  VX .  By  modelling  incon¬ 
sistent  lower  bounds,  we  can  capture  flow  relations  of  the  sort:  information 
is  allowed  flow  from  a  to  6,  or  from  a  to  c  but  not  both. 

In  this  report  we  develop  a  high  water  mark  mechanisms  that  can  en¬ 
force  flow  policies  described  as  conglomerate  relations.  The  mechanisms  we 
propose  are  currently  suitable  only  for  enforcing  conglomerate  relations  with 
consistent  lower  bounds,  i.e.,  policies  from  lZ[cla$ses}.  Thus,  in  this  report 
we  will  not  consider  policies  that  may  have  inconsistent  lower  bounds. 
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5  Separation  and  Aggregation  as  Flow  Proper¬ 
ties 

In  this  section  we  will  show  how  a  conglomerate  relation  might  be  used  to 
represent  the  flows  and  flow  policy  for  a  system.  We  will  illustrate  how 
conglomerate  relations  can  capture  aggregation  and  separation  (of  duty) 
properties.  Section  5.3  will  define  what  is  meant  by  secure  information  flow. 

5.1  System  Abstraction 

A  conglomerate  of  entities  is  used  to  represent  a  set  of  entities  that  source 
some  information,  in  concert.  Define  the  set  of  all  possible  abstract  systems 
to  be 


systems  ==  7l[ents] 

Given  some  system  5  :  systems,  then  for  E  :  Vents  and  /  :  ents,  E  /  €  5 
means  that  information  can  flow  from  conglomerate  of  entities  E  to  entity 
/  over  the  lifetime  of  the  system  5.  This  can  flow  relation  is  an  abstraction 
of  the  functionality  of  the  system  and  can  capture  more  properties  about 
the  information  flow  than  the  simple  entity  to  entity  relation  described  in 
section  3. 

How  does  the  constraints  defined  on  conglomerate  relations  reflect  rea¬ 
sonable  requirements  for  information  flow  in  systems?  The  ‘reflexivity’  re¬ 
quirement  ensures  that  information  can  always  flow  from  an  entity  to  itself. 

Example  5  A  simple  system  has  two  entities  A  and  B.  which  correspond 
to  a  file  and  a  user.  This  system  will  permit  information  to  flow  only  from 
the  file  A  to  user  B,  and  not  in  the  other  direction.  The  flows  in  the  system 
can  be  captured  by 

Simple  =  {A}  B 

This  system  contains  no  aggregation  or  separation  exceptions.  A 

Example  6  A  system  maintains  coordinate  information  in  files  Long  and 
Lat,  and  has  a  single  user,  SysOp.  The  system  enforces  an  aggregation 
policy  such  that  the  system  operator  may  only  view  one  of  the  files.  The 
information  flows  in  this  system  can  be  captured  by  schema  Coord-System. 
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_ Coord-System _ 

S  :  systems 

S  =  {Long}  SysOpll 
{Lot}  'V*  SysOp 


We  will  use  the  schema  notation  as  a  convienent  way  of  packaging  up  an 
abstract  system. 

In  this  system,  there  is  no  flow  from  conglomerate  {Long,Lat}  to  SysOp , 
implying  that,  while  the  individual  flows  can  occur,  a  flow  from  the  longitude 
and  latitude  file  (an  aggregate)  is  not  possible. 

This  policy  is  not  a  particularly  practical  example  of  an  aggregation 
policy,  but  gets  across  the  idea  of  aggregation  in  a  simple  mariner.  Lunt 
[17],  argues  that  by  appropriate  normalisation  such  a  policy  should  not  be 
expressed  in  terms  of  aggregation.  However,  Meadows[20]  shows  that  there 
are  useful  policies  that  are  best  expressed  as  aggregation  policies.  We  will 
examine  these  policies  in  later  sections.  A 

In  addition  to  representing  aggregation  scenarios  (as  in  the  last  example), 
conglomerate  relations  can  also  capture  separation  of  duty:  a  flow  EuE'  <—  f 
is  allowed,  but  E  •—  /  is  not.  Separation  of  duty  policies  are  normally  viewed 
as  control  or  integrity  policies,  and  examples  of  these  will  be  given  in  section 
11.  The  next  example  example  looks  at  separation  and  information  flow. 

Example  7  A  university  examinations  system  maintains  two  files  about 
students:  Health,  which  gives  (some)  details  on  student  health,  and  Exams. 
which  gives  their  marks  from  recent  exams.  The  Head  of  department  scans 
though  both  files  and  determines  the  final  mark  for  each  student.  College 
policy  dictates  that  the  health  file  must  be  consulted,  so  that  a  ‘borderline' 
student  with  health  problems  may  be  considered  favourably.  Thus,  the 
system  must  implement  a  form  of  separation  policy,  in  that  the  head  may 
look  at  both  files  in  concert,  but  not  individually.  However,  whether  the 
head  acts  appropriately  on  the  health  information  cannot  be  controlled — 
the  policy  only  ensures  that  (some)  health  information  was  consulted.  The 
flows  of  such  a  system  might  be  described  by 

_  Results-DB _ 

5  :  systems 

S  =  {Health, Exams)  <—*  Head 
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The  presence  of  the  flow  {Exams, Health)  to  Head ,  implies  that  conglom¬ 
erate  information  from  exams  and  health  can  flow  to  the  head,  however 
individually  exams  and  health  cannot  flow  to  the  head.  Separation  (flow) 
policies  will  be  considered  in  section  8.  A 

5.2  Information  Flow  Policies 

An  information  flow  policy  defines  the  flows  that  are  allowed  between  the 
classes  of  information  in  the  system.  The  structure  of  the  flow  policies 
discussed  in  section  3  imply  the  existence  of  consistent  upper  and  lower 
bound  operators.  This  implies  that  if  information  is  allowed  flow  from  a  to 
c  and  from  b  to  c,  then  an  aggregate  or  join  of  information  of  class  a  and 
b  is  allowed  flow  to  c.  However,  as  has  already  been  pointed  out.  we  may 
wish  to  design  systems  where  this  does  not  hold,  i.e.,  a  may  flow  to  c.  b 
may  flow  to  c,  but  a  and  b  may  not  flow  to  c.  Thus  we  will  describe  an 
information  flow  policy  as  a  conglomerate  relation,  which  will  allow  us  to 
enumerate  how  collections  of  information  may  flow. 

A  conglomerate  of  classes  is  us-  j  to  represent  information  that  has  orig¬ 
inated  from  the  classes  in  the  conglomerate,  in  concert.  Define  the  set  of 
information  flow  policies  to  be 

policies  ==  K[classes] 

Given  a  policy  P  :  policies,  A  •—  6  £  P  means  that  information  is  allowed 
flow  from  class  conglomerate  A  to  class  a. 

The  constraints  on  conglomerate  relations  also  apply  to  policies:  it  is 
implicitly  assumed  that  information  may  always  flow  to  itself,  regardless  of 
the  conglomerate. 

Example  8  The  traditional  military  ordering  can  be  described  as 

_  Military _ _ 

P  :  policies 

P  =  {classified} secretU 

{classified, secret}  top-secret 


Note  how  every  permitted  conglomerate  flow  must  be  enumerated.  A 

Example  9  Continuing  with  the  coordinates  example,  a  flow  policy  can  be 
defined  to  describe  the  appropriate  flow  restrictions  Let  classes  lat  and 
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long  represent  latitude  and  longitude  information,  and  let  op  represent  the 
class  of  information  that  an  operator  is  allowed  handle.  The  flow  policy  can 
be  captured  as 

Coords-Pol _  _ 

P  :  policies 

P  =  {long}  op  U  {lat}  op 


In  this  policy  latitude  or  longitude  information  is  allowed  flow  to  class  oper¬ 
ator,  however,  an  aggregate  of  longitude  and  latitude  (information  sourced 
from  class  lat  and  long  in  concert)  is  not  allowed  flow  to  the  operator.  A 

Example  10  A  private  hospital  information  system  processes  information 
of  class  recs  (medical  history);  treat  (treatments  given  to  patients);  acc 
(patient  accounts);  dir  (shareholder  information);  and  mgmt  (information 
handled  by  management).  How  information  may  flow  between  these  different 
classes  is  described  by  the  reflexive  relation  in  figure  1.  Note  how  treat 


recs  dir 


Figure  1:  Flow  policy  HOSPITAL 

information  is  allowed  flow  to  recs  or  mgmt,  but  fo.  confidentiality  reasons, 
cannot  flow  to  class  dir.  Similarly,  acc  information  is  not  allowed  flow  to 
recs  (for  profitability  reasons).  Management  is  allowed  coordinate  all  this 
information  given  these  constraints. 

This  policy  (taken  from  [11])  can  be  described  as  the  conglomerate  rela¬ 
tion 
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.—  Hospital _ 

P  :  policies 

P  =  {treat, acc} mgmtU 
{treat ,mgmt}  recU 
{acc.mgmt}  'v*  dir 


A 

Example  11  Users  of  a  dial-up  stock  market  database  must  be  aware  of 
charges  when  they  access  stock  information.  This  can  be  captured  by  the 
separation  policy 

_ Stock-Pol_ _ 

P  :  policies 

P  =  {charges} userU 

{charges .stock}  <—  user 


A  user  is  always  allowed  sink  charges  information,  but  may  only  sink  stock 
information  as  a  conglomerate  with  charges  information.  A 

When  describing  a  separation  flow  policy,  one  must  realise  that  the  sep¬ 
aration  is  based  on  flou's ,  not  control.  Thus  we  call  them  separation  flow 
policies.  In  the  example  above  the  user  is  allowed  sink  information  based 
on  both  stock  and  charges  information.  This  user  can  in  turn  forward  this 
aggregate  information  to  any  other  user.  Separation  policies  are  considered 
further  in  sections  8  and  11. 

5.3  Secure  Information  Flow 

Recall  the  multilevel  security  requirement  for  information  flow  policies  as, 

if  information  can  flow  from  class  a  to  class  6  in  a  system  implies 
that  a  i-*  i  must  hold  in  the  policy. 

This  can  be  restated  for  conglomerate  flow  polices  as, 

if  information  can  flow  from  class  conglomerate  A  to  class  6  in  a 
system,  implies  that  A  *-*  b  must  hold  in  the  policy. 
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The  relationship  between  a  system  and  a  flow  policy  is  established  by 
binding  each  entity  to  a  information  class  from  the  policy.  The  class  of  each 
entity  represents  the  class  of  information  that  the  entity  is  allowed  sink  and 
source.  Thus  the  confidentiality  policy  can  be  captured  by 

FMC-  Conf-Pol _ 

P  :  policies 

0-  :  ents  •**  classes 

ran/?_  C  aP 


Function  /3_  gives  the  information  class  from  the  flow  policy  P  for  each 
entity  of  the  system. 

A  system  is  secure  so  long  as  the  multilevel  security  requirement  is  main¬ 
tained.  Thus  a  secure  system  can  be  defined  by 

_ FMC-Secure-System _ 

FMC-Conf-Pol 
S  :  systems 

dom  &-■=  aS 
V  E  :  Vents;  f  :  ents  • 

£  *-*  /  E  5  => 

0(\E\l  -  (ie  €  P 


This  schema  states  that  a  system  5  is  secure  by  a  given  confinement  policy 
if  for  every  flow  from  entity  conglomerate  E  to  entity  /  then  the  (conglom¬ 
erate)  class  of  the  information  sourced  by  E  may  flow  to  the  class  of /.  The 
restriction  do m =  aS  ensures  that  every  entity  of  the  system  5  has  an 
information  class. 

Example  12  Consider  the  coordinates  examples  (6  and  9).  The  system 
Coord-DB  is  secure  by  policy  Coord-Pol,  since  every  possible  flow  of  the 
system  is  allowed  by  the  policy.  Suppose  the  system  contained  a  trojan 
horse  that  generated  flow  from  { Long, Lat }  to  Op,  then  the  system  would 
no  longer  be  secure  since 

\j3(\{Long,Lat,Op}\)  =  {long , lat  ,op) 

0  Op  =  op 

and  the  flow  {long , lat , op}  •—  op  is  not  allowed  in  the  policy  Coord-Pol. 
A 


Note  that  our  definition  of  a  secure  system  is  based  on  ensuring  that 
flows  between  individual  entities  are  secure,  as  opposed  to  ensuring  flows 
between  all  entities  of  one  class  to  all  entities  of  another  class  are  secure. 
In  the  coordinate  example,  we  do  not  consider  the  possibility  of  two  opera¬ 
tors  colluding:  one  operator  reads  longitude  information,  and  another  reads 
latitude  information.  This  can  be  avoided  by  using  entities  to  represent  per¬ 
sistent  knowledge  environments[19].  If  it  was  felt  that  operators  in  the  same 
building  would  collude,  then  we  could  represent  the  building’s  network  as  an 
entity  of  class  op.  As  soon  as  somebody  on  the  network  accesses  longitude 
information,  the  network’s  class  changes,  and  nobody  in  that  building  can 
subsequently  access  latitude  information. 

5.4  Choosing  a  Flow  Semantics 

In  the  following  sections  we  will  look  at  how  we  can  construct  general  mech¬ 
anisms  for  enforcing  arbitrary  conglomerate  flow  policies.  We  shall  see  in 
section  8  that  it  is  not  practical  to  implement  state  mechanisms  that  can 
enforce  any  conglomerate  policy,  and  therefore  we  seek  to  collect  a  selection 
of  mechanisms  that  can  enforce  interesting  classes  of  policy.  Section  6  looks 
at  a  general  mechanism  for  enforcing  aggregation  policies,  and  section  8, 
separation  policies. 

One  of  the  simplest  classes  of  flow  policies  are  conglomerate  relations 
that  form  quasi  ordered  sets.  We  know  that  such  policies  are  easily  enforced 
using  traditional  state  based  flow  models.  The  following  holds  for  systems 
that  enforce  quoset  policies, 

VFMC-Secvre-System  • 

P  €  <7uoset[c/asses]  => 

3  Secure-System'  • 

P=P’A0.=  3'.A 
S  €  quoset[ent$ ]  A  S'  C  S 

This  theorem  tells  us  that  given  any  secure  system  that  enforces  a  quoset 
flow  policy,  then  it  is  always  possible  to  add  extra  (secure)  flows  to  the  sys¬ 
tem  so  that  the  system  also  forms  a  quoset.  Therefore  if  we  are  interested  in 
only  enforcing  quoset  policies,  we  need  not  look  for  an  information  flow  se¬ 
mantics  that  can  capture  transitivity,  aggregation  or  separation,  exceptions. 
Similar  conclusions  can  be  made  about  reflexive  policies  (the  semantics  need 
not  express  aggregation  or  separation  properties),  and  aggregation  and  sep¬ 
aration  policies. 
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6  Implementing  Aggregation  Policies 

In  [11,12]  a  model  was  proposed  that  could  be  used  to  enforce  aggregation 
policies.  We  will  now  demonstrate  how  this  model,  the  group  confinement 
model,  can  be  used  to  enforce  any  conglomerate  policy  that  does  not  posses 
separation  properties  (i.e.,  policies  from  7£_s[ctasses])-  The  group  confine¬ 
ment  model  is  implemented  using  a  generalisation  of  a  high  water  mark 
model. 


6.1  FMG:  Group  Confinement  Model 

In  the  group  confinement  model  the  confidentiality  policy  is  described  by 
a  lattice  flow  policy  and  entities  are  bound  to  classes  from  this  lattice  as 
described  below. 

FMG-conf-pol[C ] _ 

L  :  lattice[C } 

:  ents  -**  C 
0ts  -  '■  ents  -+♦  V\C 

dom  =  dom  3ts 
V  e  :  dom  3±  • 

0±e  €  dom(L  t>  pjse) 


Lattice  L  gives  the  flow  policy.  Its  components  can  be  instantiated  as  classes 
or  if  desired  as  sets  of  classes  if  a  powerset  lattice  policy  is  used.  Every  entity 
is  bound  to  a  set  of  intervals  from  L  (all  with  the  same  lower  bound  3± ),  and 
the  upper  bounds  are  given  by  the  set  3rs-  This  entity  binding  is  interpreted 
as: 


•  entity  e  may  source  information  at  class  @±  or  higher,  and 

•  may  sink  information  at  any  class  a  6  0js  or  lower. 

This  binding  is  subject  to  the  multilevel  security  requirement.  The  group 
confinement  model  can  be  defined  in  abstract  terms  as: 
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_ FMG-Secure-Sys1em[C] _ 

FMG-conf-pol 
S  .  systems 

dom  /3±  =  aS 
V  E  :  Vents\  f  :  ents  • 

E  f  £  S  => 

©/MED e  dom(i  >  /?t ,/) 


A  system  is  considered  secure  if  for  every  conglomerate  flow  E  *-*  f  in  the 
system,  then  the  class  of  information  generated  by  E  (i.e.,  the  lowest  upper 
bound  of  the  class  of  information  each  e  6  E  can  source)  must  be  permitted 
to  flow  to  entity  /  (i.e.,  there  must  be  some  class  in  /3jsf  that  dominates 
the  class  of  the  source  information). 

Note  how  this  characterisation  of  a  secure  system  can  enforce  aggregation 
exceptions:  an  entity  may  be  allowed  sink  information  of  class  a  or  class  b 
but  not  both  if  their  join  (a  ®  6)  is  not  dominated  by  some  component  of 
/3t,  •  We  shall  see  later  how  the  shape  of  the  bindings  of  entities  determine 
the  class  of  policy  enforced. 

We  now  propose  a  function  that  transforms  an  arbitrary  aggregation 
policy  into  a  lattice,  plus  sets  of  intervals  for  each  class  (of  the  form  defined 
in  FMG-conf-pol).  Given  some  aggregation  policy  P  :  7 v_5[c/asses]  and 
a.b  £  aP ,  then  b  forms  a  bound  on  a,  if  it  dominates  a  in  the  policy,  and 
every  thing  that  conglomerates  involving  b  can  flow  to,  then  a  can  al»o  flow 
to.  i.e.,  if  a  <  b  where 

(P)a  <  b  o  {a,  6}  i-  b  €  P  A 

V  B  :  V classes;  c  :  classes  • 

B  U  {b)  ^  c  £  P  =>  Bu{a,6}  •—  c  £  P 

Define  the  set  of  all  bounds  of  class  a  to  be 

bounds  P  a  =  {b  :  classes\(P)b  <  a} 

We  now  define  a  mapping  from  aggregation  policy  P  to  intervals  of  a  pow- 
erset  lattice  VcaP  by 
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$_L_  :  policies  -+♦  ( classes  -++  V classes) 
$T,-  :  policies  •**  ( classes  ■+*  W classes) 


V  P  :  policies  • 

P  6  7 2_s  [classes]  => 

$xP  =  {fl  :  c/asses|a  €  oP  •  a  *->  bounds  P  a}  A 
$T,  P  =  {a  :  classesja  €  Q P  •  a  •-»  maxs(dom  P  >  {a})} 

The  mapping  is  flow  preserving,  in  the  sense  that  for  any  aggregation  policy 
P  :  72 [c/asses],  we  have 

V  >1  :  V classes',  b  :  classes  • 

A  U  {6}  C  aP  => 

(A  —  b  €  P)  3P  €  4>TjP  b  •  U*jl(MD  £  B 

Note  the  similarity  between  the  relation 

U*±(MK  B 

and  the  test  for  security  in  the  FMG-Secure-System  schema.  We  can  enforce 
any  aggregation  policy  using  the  group  confinement  model  and  the  transfor¬ 
mation  above  were:  an  entity  e  bound  to  class  a  in  the  aggregation  policy 
P  :  72_s[classes]  will  have 

0±e  -  $xP  c 

0 T,e  =  Qr,P  a 

with  a  powerset  lattice  policy  VcaP.  Thus  systems  enforcing  aggregation 
policies  can  be  characterised  by 

_ Aggregation- Secure- System _ 

FMG-Secure-System[P  classes] 

FMC-conf-pol 

P  €  7l-s[classes] 

L  =  VcaP 

0±-  =  0-i(*i  P) 

0T,~ =  0-%{$T  ,P) 


Since  $  is  flow  preserving,  it  follows  that  any  such  (secure)  group  con¬ 
finement  system  is  also  a  secure  conglomerate  system,  i.e., 

V  Aggregation-Secure-System  • 

FMC-Secure-System 
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The  flow  preserving  mapping  maps  an  aggregate  policy  P  to  a  powerset 
lattice  VcaP.  If  P  has  a  large  number  of  components,  then  VcaP  will 
be  even  larger.  We  can  improve  on  the  mapping  using  the  optimal  flow 
preserving  mapping  proposed  by  Denning[9]  as  follows 

1.  Given  a  aggregate  policy  P,  create  a  partially  ordered  set  Q  with 
components 

pOqPDuU^t,  PQaPD 

and  an  ordering  relation  defined  by  subset. 

2.  Denning  gives  a  terminating  algorithm  that  takes  an  arbitrary  poset  (a 
subset  of  a  powerset  lattice),  and  adds  additional  components  so  that 
each  element  has  a  unique  lowest  upper  and  greatest  lower  bounds. 
Use  this  algorithm  on  the  poset  Q,  to  give  the  lattice  to  be  enforced 
by  the  high  water  mark  model. 

Example  13  Consider  the  coordinates  example  9.  Table  1  gives  the  flow 
preserving  mappings  for  classes  op.  lat,  and  long.  The  lattice  to  be  used  by 


class 

^iCoords 

Coords 

op 

{°P} 

{{op, long}. {op, lat}} 

long 

{long} 

{{long}} 

lat 

{lat} 

{{lat}} 

Table  1:  Bindings  for  Coordinate  Flow  Policy 

FMG  can  be  either  the  powerset  lattice  Vc {op , lat  .long) .  or  the  lattice  in 
figure  2,  generated  using  Denning’s  transformation  on  the  poset  generated 
by  $.  A 


6.2  iFMG:  A  State  based  Refinement  of  FMG 

We  w'ill  chose  a  system  model  that  is  an  abstraction  of  the  traditional  manda¬ 
tory  access  control  models.  Since  we  are  concerned  with  just  the  mechanisms 
for  enforcing  the  confidentiality  policy,  the  model  is  considerably  stripped 
down:  we  have  a  fixed  set  of  entities  throughout  the  the  life  of  the  system, 
and  only  flows  due  to  accesses  are  modelled,  not  actual  accesses. 
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{  op.long.lat  } 


Figure  2:  Transformed  Coordinate  Lattice 

Firstly,  we  identify  two  kinds  of  system  entities:  memorable  ( mcmblt ) 
and  memoryless  (memless) 

memless, 
memblt  :  Vents 

memble  D  memless  =  {} 

A  memorable  entity  is  an  entity  that  can  ‘remember’  information  sunk  to 
it,  and  is  liable  to  forward  that  information  at  any  later  state.  An  example 
of  a  memorable  entity  is  a  file:  information  written  to  a  file  can  be  retrieved 
later  by  performing  a  read.  A  memoryless  entity  is  an  entity,  which  having 
sunk  information  will,  in  essence,  forget  the  information  and  is  relied  on  not 
to  source  that  information  at  a  later  state.  An  example  of  a  memoryless 
entity  is  a  trusted  subject:  it  is  trusted  not  to  source  (inappropriately)  any 
information  sunk.  In  the  original  definition[l  1)  of  the  group  confinement 
model  only  memorable  entities  were  considered. 

A  state  of  a  system  captures  the  flows  that  could  occur  due  to  the  accesses 
during  that  state.  These  ‘access  flows’  are  drawn  from  the  set: 
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acc-flows  :  V{ents  *-*  ents) 


acc-flows  -  {A  :  ents  <-*  ents| 

dom  A  C  memble  U  memless  A 
id  A  C  A  A 

A  >  memble  |  A  C  A} 

Information  flow  is  assumed  to  be  reflexive.  Information  flow  through  mem¬ 
orable  entities  is  assumed  to  be  transitive:  if  entity  e  writes  to  memorable 
entity  /  and  entity  g  can  read  entity  /,  then  there  is  also  a  flow  from  e  to  g. 
A  memoryless  entity  does  not  necessarily  ‘propagate’  information  from  its 
sources  to  its  sinks.  Since  we  are  modelling  only  flows  due  to  accesses,  we 
assume  that  there  are  no  aggregation  properties  on  memorable  entities:  i.e, 
if  information  can  flow  from  entity  e  to  memorable  entity  /  and  from  entity 
g  to  entity  /,  then  there  there  is  also  an  implicit  flow  from  conglomerate 
{ e,g }  to  /.  If  /  is  memoryless,  then  we  assume  that  it  forgets  one  while 
viewing  the  other.  Thus  we  choose  to  represent  the  flows  as  a  simple  relation 
between  single  entities.  Section  8  will  consider  a  more  elaborate  scheme  for 
modelling  flows  at  a  state. 

A  secure  state  in  the  IFMG  model  is  defined  as 

_Secure-5tate[C] _ 

FMG-conf-poI[thum/3±:  6i,mt/i3 tJ 
A  :  acc- flows 

dom  A  —  dom  bhwTn 
V  e,f  :  ents  • 

c  •— >  /  €  A  >  memble  => 
fthwmt  bhumf  6  L 
e  *—  /  €  A  >  memless  => 

^ hwm ^  ^  dom(L  C>  blimsf) 


Each  entity  e  has  a  current  high  water  mark  given  by  •  This  can  be 

thought  of  as  representing  the  class  of  information  that  the  entity  has  sunk 
to  date.  The  set  6i,ma  gives  the  limits  to  which  the  high  water  mark  may 
rise.  The  flow’s  for  the  current  state  are  given  by  A.  A  state  is  secure  if, 
for  every  flow  e  >-►  /  p  A,  (memorable  /)  then  the  class  of  information  held 
by  e  must  be  dominated  by  the  class  of  /.  If  /  is  memoryless,  then  any 

use  6  for  any  variable  that  can  change  as  a  system  progresses 
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information  sunk  is  immeaditally  ‘forgotten’,  and  thus  its  high  water  mark 
need  not  reflect  the  information  it  has  sunk.  Therefore  the  flow  is  secure  so 
long  as  /  may  sink  the  information. 

The  initial  state  does  not  permit  any  flows  except  reflexivity 

Initial- State[C] _ _ 

Secure-State 

A  =  id  A 


When  a  system  makes  a  transition  from  one  state  to  another  (as  a  result 
of  some  access  requests),  the  lattice  policy  and  system  entities  must  remain 
fixed.  However,  the  high  water  marks  are  allowed  to  float  upwards  to  reflect 
the  information  they  may  hold.  As  the  high  water  marks  rise,  certain  limits 
may  have  to  be  removed  so  that  the  bindings  are  still  valid  (i.e.,  so  that  the 
bums  dominate  the  high  water  mark).  Note  that  the  bindings  of  memoryless 
entities  remain  static  as  they  ‘forget'  between  states.  In  [11]  we  show  how 
to  calculate  the  new  high  water  marks  (for  memorable  entities)  in  a  precise 
manner.  This  is  reflected  in  the  definition  of  a  secure  transition: 

_ Secure -  Trans[  C]  .  _ 

A5ecz/re-State[C] 

L-L' 

dom  A  =  dom  A' 

V  e  :  ents  • 

e  £  (dom  bkwm  )  n  membk  => 

Kwm*  =  dom  A'  t>  (e}[)  A 

b'um,*  Q  hm,e  n  dom({^u,me}  <  L) 
e  £  (dom  6hu.m )  fl  memless  => 
b k-wme  ~  bhwmC  A 
bhmse  =  bumse 


This  mechanism  provides  us  with  the  ability  to  enforce  aggregation  policies: 
a  high  water  mark  may  drift  towards  any  limit,  but  as  it  does  so,  certain 
other  limits  are  removed,  and  the  entity  may  no  longer  access  information 
at  those  classes. 

A  system  is  characterised  by  an  initial  state;  a  state  transition  function 
and  a  set  of  reachable  states.  The  system  is  secure  if  the  basic  security 
theorem  holds: 
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Theorem  1  A  system  is  secure  if  it  starts  from  a  valid  initial  state,  and 
if  every  state  transition  achievable  by  the  transition  function  is  a  secure 
transition.  Such  a  secure  system  can  be  characterised  by 


iFMG-Secure-System[C] 

Initial-State 

E  :  V  Secure- Trans 


□ 

Example  14  Consider  the  coordinates  example  13.  Table  1  gave  the  flow 
preserving  mappings  (page  30).  If  the  system  operator  is  memorable  then, 
from  the  initial  state  he  may  enter  a  state  with  access  to  longitude  informa¬ 
tion,  or  a  state  with  access  to  latitude  information.  He  may  not  enter  a  state 
with  access  to  both.  If  he  enters  a  state  with  access  to  longitude  informa¬ 
tion,  his  high  water  mark  needs  to  rise  to  match  the  class  of  information  he 
has  sunk,  i.e.,  class  {op .long},  and  this  results  in  the  removal  of  {op.lat} 
from  his  6ilms  ensuring  that  latitude  information  cannot  be  accessed. 

Note  that  in  this  simple  example,  it  is  the  class  of  the  user  (the  system 
operator)  that  changes,  and  thus  there  is  no  oppertunitv  for  a  covert  channel 
due  to  denial  of  access.  However,  suppose  the  system  operator  owned  a 
file  (memorable)  that  had  class  op.  This  file,  if  shared,  can  be  used  to 
create  a  covert  channel:  the  system  operator  could  first  read  some  longitude 
information;  a  trojan  horse  will  then  access  latitude  information  and  if  the 
coordinate  is  above  the  equator,  it  writes  it  to  the  operator's  file,  if  it  is 
below  the  equator  it  does  nothing.  By  testing  for  denial  of  access  on  the 
file,  the  operator  can  determine  what  hemisphere  the  coordinate  is.  This 
problem  is  addressed  further  in  [11],  A 

6.3  Formal  Basis  for  iFMG 

To  justify  that  an  iFMG  system  is  secure,  in  the  sense  of  the  abstract 
model,  it  is  necessary  to  prove  that  iFMG-Secure-System  is  a  refinement 
of  FMG-Secure-System  (and  thus  a  suitable  refinement  of  a  secure  conglom¬ 
erate  system  enforcing  aggregation  policies).  Thus  we  need  to  construct  an 
abstraction  mapping  between  the  abstract  FMG  and  the  state  based  iFMG 
model,  and  prove  that  a  system  secure  by  the  state  based  model  will  also 
be  secure  by  the  abstract  model.  This  has  already  been  done  in  [11],  and  it 
is  not  pursued  further. 


34 


6.4  A  Framework  of  High  Water  Mark  Models 

When  enforcing  an  aggregation  policy  using  the  group  confinement  high 
water  mark  model,  the  binding  of  an  entity  at  any  state  can  be  pictured  as 
in  figure  3.  The  entity  is  allowed  sink  any  information  that  appears  under 
and  source  information  at  or  above  Skwm.  The  area  between  6h.wm  and 


Figure  3:  High  Water  Mark  for  Aggregation  Policies 

^hma  gives  the  allowable  future  high  water  marks  for  the  entity.  As  the  high 
water  mark  rises,  the  set  of  possible  future  high  water  marks  diminish.  If 
6hu-m  heads  towards  the  limit  a,  then  the  limit  at  6  will  eventually  disappear, 
so  that  the  entity  no  longer  has  a  potential  to  read  information  at  this  class 
(6).  This  forms  the  basis  for  the  implementation  of  aggregation  policies. 

Policy  join  (U)  is  closed  over  aggregation  policies,  implying  that  we  can 
build  a  policy  to  be  enforced  by  the  group  confinement  model,  based  on  a 
collection  of  smaller  aggregation  policies.  An  example  of  this  is  the  Chinese 
wall  policy  in  example  17. 

6.4.1  Reflexive  Policy  Model 

If  a  flow  policy  P  is  reflexive  (i.e.,  a  member  of  TZo[classes])  then  each 
class  will  have  only  a  single  maximum  in  $T ,P,  since  we  know  that  for 
4,  B  :  Vclasses;  c  :  classes  then 

(4*—  c£P)f\(B*-*c£P)^>A\JB>— c£P 


and  we  have 

$t,  P  a  =  {(Jdom  P  >  {a}} 
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Given  this,  the  conditions  on  states  and  state  transitions  simplify  consider¬ 
ably:  each  entity  is  bound  to  a  high  water  mark  and  a  single  static  limit.  The 
resulting  state  machine  model  is  the  interval  confinement  model  described 
in  [10]. 

Policy  join  (U)  is  closed  over  reflexive  policies,  implying  that  we  can 
build  a  policy  to  be  enforced  by  the  interval  model,  based  on  a  collection  of 
smaller  reflexive  policies. 

The  binding  of  each  entity  can  be  pictured  as  in  figure  4.  An  entity  can 


Figure  4:  High  Water  Marks  for  Reflexive  Policies 

sink  anything  below  6ums.  and  can  source  anything  above  hum  ■  The  high 
water  mark  may  rise  to  any  class  in  the  area  bounded  by  this  interval.  As 
the  high  water  mark  rises,  there  are  (lower)  classes  that  the  entity  can  no 
longer  source  to.  However,  the  entity  can  always  sink  everything  under  the 
single  6ums  (i  e.,  there  are  no  aggregation  exceptions). 

This  class  of  high  water  mark  mechanism  is  similar  to  the  high  water 
mark  mechanism  adopted  by  the  Compartmented  Mode  \Vorkstation[2G]. 
with  all  entities  memorable.  Thus  we  conclude  that  the  policies  enforced  by 
the  CMW  can  be  classed  as  reflexive.  The  high  water  marks  of  memoryless 
entities  are  static,  and  they  can  be  compared  to  partially  trusted  subjects[3]. 

6.4.2  Quasi  Ordered  Policy  Model 

If  the  policy  to  be  enforced  form  a  quoset,  then  the  flow  preserving  mapping 
simplifies  even  further  to,  for  P  :  quoset  [c/asses]:  a  :  classes, 

$j.  P  a  =  [Jdom  P  >  {a} 

$t,  P  a  =  {[JdomP  >  {a}} 
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which  corresponds  to  the  Birkoff  mapping[5].  that  maps  a  quasi  ordered  set 
to  a  powerset  lattice.  In  this  case  the  high  water  mark  model  corresponds  to 
the  traditional  lattice  model,  with  each  entity  bound  to  a  static  class  drawn 
from  a  lattice.  Binding  is  static  since  6hwm  is  already  at  the  limit,  and  thus 
cannot  rise. 
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7  Examples 

7.1  Reflexive  Policies 

Example  15  Consider  the  simple  military  policy  in  example  8.  Suppose  we 
wish  to  extend  this  by  introducing  two  new  classes  admiral  and  general. 
Class  admiral  has  no  restrictions  on  the  information  classes  it  may  sink 
and/or  source.  The  only  restriction  on  class  general  is  that  it  cannot  sink 
top-secret  information.  This  policy  can  be  defined  as 

Mil-2 - - - - 

P  :  policies 

P  =  Military  LI  ±{admiral}  U  {general}  •vr  toj)*s6cr6t 


Observe  the  use  of  conglomerate  join:  any  flow  is  permitted  so  long  as  it  does 
not  violate  the  three  operand  policies  Military.  _L{admiral}  (no  restric¬ 
tions  on  an  admiral),  and  {general}  top-secret  (general  is  dominated 
by  top-secret). 

This  policy  can  be  transformed  to  a  lattice  policy  by  the  mapping 
calculated  in  table  2.  The  application  of  Denning's  transformation  on  these 


class  a 

$j.  Mil-2  a 

<J>t  Mil-2  a 

classified 

{c.g.a} 

{c.g.a} 

secret 

{c.s.g.a} 

{c.s.g.a} 

top-secret 

{c.s.t.g.a} 

{c.s.t.g.a} 

general 

{c.g.a} 

{c.s.g.a} 

admiral 

{c.g.a} 

{c.s.t.g.a} 

Table  2:  Bindings  for  policy  Mil-2 


classes  give  a  simple  total  ordering  (lattice), 

{c.g.a}  C  {c.s.g.a}  C  {c.s.t.g.a} 

• 

which  is  simply  a  re-labeling  of  the  original  military  lattice.  If  an  admiral  A 
is  bound  to  class  admiral,  then  in  the  model  he  gets  bound  to  the  interval 
pair  ({c,g,a},  {c,s,t,g,a}).  This  entity  A  is  memorvless— he  is  trusted 
to  handle  admiral  information  appropriately,  and  therefore  may  simulta¬ 
neously  sink  and  source  any  class.  If  the  general  creates  a  (memorable) 
file,  it  would  initially  be  assigned  class  admiral,  and  if  secret  information 
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were  sunk  to  that  file,  its  high  water  mark  needs  to  rise  to  reflect  the  file’s 
contents. 

Thus  any  memoryless  entity  bound  to  class  admiral  is  like  a  trusted  sub¬ 
ject  bound  to  the  interval  classified,  top-secret;  a  memorable  entity  bound 
to  class  admiral  is  like  an  object  with  an  initial  high  water  mark  classified, 
that  may  rise  to  top-secret.  A  memoryless  entity  bound  to  class  general  is 
like  a  partially  trusted  subject  who  is  trusted  to  handle  classified  and  secret 
information  appropriately.  A  memorable  entity  bound  to  general  is  like  an 
entity  with  an  initial  high  water  mark  of  classified,  that  is  allowed  rise 
to  the  limit  secret.  A 

In  the  last  example  the  new  policy  Mil-2  can  be  thought  of  as  a  refine¬ 
ment  of  Military,  i.e.,  we  have 

Military  C  Mil-2 

It  is  possible  when  developing  a  policy  to  end  up  with  an  unintentionally 
restrictive  result.  For  example,  if  a  policy  was  defined  as 

Mil-3  =  Mil-2  U  {top-secret}  secret 

we  have  Mil-2  C  Mil-3,  but  this  new  policy  no  longer  permits  information 
flow  from  secret  to  top-secret.  Thus,  when  building  complex  policies  it  is 
worth  investigating  how  much  of  the  original  policies  are  preserved.  For 
example  15,  we  have 

military  =  Mil-2SaMilitary 

which  gives  reassurance  that  the  new  policy  preserves  the  original  intentions 
of  policy  Military. 

ExampltrlO  The  hospital  policy  (example  10)  is  transformed  by  the  flow 
preserving  mapping  given  in  table  5  to  the  lattice  with  components 

{{},{t},{a},{t,m},{t,m,r}, 

{t,m,a},{d,m,a},{t,m,a,d,r}} 

where  each  class  is  denoted  by  its  first  letter.  In  this  example,  a  hospital 
administrator  would  be  bound  to  class  mgmt.  For  the  policy  to  work  effec¬ 
tively,  the  administrator  should  be  modelled  as  memoryless:  he  is  trusted  to 
handle  treatment  and  accounts  information  appropriately,  i.e.,  not  forward 
treatments  onto  shareholders.  Any  files  he  may  create  should  be  memorable 
so  that  their  high  water  marks  reflect  the  information  class  they  contain.  A 
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class 

$xHospital 

$t3  Hospital 

treat 

{t> 

{t} 

acc 

{a} 

{a} 

mgmt 

{m} 

{t.m.a} 

recs 

{t ,m,r} 

{t,m,r} 

dir 

{d.rn.a} 

{d.m.a} 

Figure  5:  Flow  Preserving  Mapping  for  Hospital-Pol 

7.2  Aggregation  Policies 

Example  17  A  stockmarket  database  holds  confidential  information  on  dif¬ 
ferent  organisations.  A  unique  information  class  (‘dataset’)  is  used  to  denote 
the  information  of  each  company.  Consultants  are  allowed  access  the  infor¬ 
mation  held  in  the  database.  We  have, 

Orgs  :  V classes 
cons  :  classes 

where  Orgs,  is  the  set  of  all  organisation  information  classes,  and  cons 
denotes  the  class  of  information  that  may  be  handled  by  consultants. 

Organisations  can  be  organised  in  terms  of  conflict  (of  interest)  sets.  Two 
companies  occur  in  the  same  conflict  set  if  they  have  conflicting  interests. 
A  conflict  set  is  of  type 

conflict-set  ==  V\Orgs 

A  number  of  (possibly  intersecting)  conflict  sets  may  defined  over  a  set  of 
organisations.  For  example,  a  bank  might  also  have  an  insurance  business, 
and  thus  may  appear  in  both  the  banks  and  insurance  conflict  of  interest 
sets. 

The  information  in  a  conflict  class  must  be  kept  disjoint:  one  bank  is 
not  allowed  find  out  anything  about  another  bank.  A  consultant  is  allowed 
access  to  the  information  on  any  one  bank,  but  no  more.  Thus  if  a  consultant 
is  modelled  as  memorable,  the  conflict  policy  for  a  conflict  set  C  can  be 
defined  by  conflict-pol  C,  where 

conflict-pol _  :  conflict-set  —>  policies 

V  C  :  conflict-set  • 

conflict-pol  C  =  T(Cu  {cons})U 
U{c  :  C  •  {c}  cons} 


40 


A  consultant  is  allowed  consult  for  any  number  of  organisations  so  long 
he  preserves  the  conflict  policy  for  every  conflict  of  interest  class,  i.e.,  he 
can  consult  for  any  group  of  organisations  so  long  as  they  have  no  conflict 
of  interest. 

Suppose  there  are  three  conflict  of  interest  sets  for  banks,  insurance 
companies  and  oil  companies.  The  flow  policy  in  this  case  can  be  captured 
by  the  Chinese  wall 

■  4 

j—Chinese-Wall _ _ 

P  :  policies 

Banks,  Oil,  Insurance  :  conflict-sets 

P  =  conflict-pol  BanksU 
conflict-pol  OilU 
conflict-pol  Insurance 


A 

Example  18  The  Chinese  wall  policy  in  the  last  example  was  only  con¬ 
cerned  with  constructing  a  wall  around  the  consultant,  and  did  not  consider 
how  organisations  that  do  not  have  conflicting  interests  should  relate  to  each 
another.  While  conflicting  classes  are  disjoint  in  Chinese-Wall,  information 
from  classes  that  do  not  conflict  can  flow  freely  between  one  another.  For 
example,  if  a,  b  £  Banks,  and  c  £  Oil  such  that  a,  b  are  not  conflicting  with 
c,  then  {a,  6}  c  is  a  valid  flow.  Therefore,  we  propose  a  modified  Chinese 
wall  where  all  organisations  are  disjoint,  as 

_ China-2 _ 

Chinese-Wall[o/d-P/P] 

P  :  policies 

P  =  old-P  U  T(Banks  U  Oil  U  Insurance) 


A 

The  conglomerate  join  operator  is  useful  for  joining  policies  with  differ¬ 
ent  alphabets  together.  However,  before  using,  the  policy  specifier  should 
be  clear  on  its  semantics.  In  example  17,  conflict-Pol  only  considers  the 
flow  restrictions  between  a  conflict  set  and  a  consultant.  When  two  con¬ 
flict  policies  are  joined  all  flows  are  allowed  that  do  not  violate  the  original 
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two  policies.  Thus,  since  a  single  conflict  policy  does  not  express  any  re¬ 
strictions  between  classes  of  different  conflict  sets,  the  resulting  Chinese  wall 
reflects  this.  Thus  a  policy  specifier  should  always  remember  that  the  flow 
restrictions  described  in  a  flow  policy  extend  only  to  the  alphabet  of  the 
policy. 

Example  19  In  any  realistic  implementation  of  a  Chinese  wall,  there  will 
exist  sanatized  information  to  which  the  conflict  policy  need  not  apply.  De¬ 
fine  the  class  of  such  information  as 

|  sanatized  :  classes 

Sanatized  information  has  no  flow  restrictions  on  it.  and  thus  a  new  Chinese 
wall  can  be  defined  as 

!_  China-3 _ 

Chinese-wall[OW-P/P] 

P  :  policies 

P  =  old-P  U  ±{sanatized} 


In  this  policy  information  from  all  banks  are  allowed  flow  to  class  sanitized, 
and  class  sanitized  is  allowed  flow  to  consultant,  but  transitivity  does  not 
follow.  Therefore  this  policy  can  only  be  successfully  implemented  by  re¬ 
classification:  A  memorvless  entity  of  class  sanitize  (typically  a  trusted 
person)  reads  all  conflict  set  information,  adds  sufficient  noise  etc.,  and 
reclassifies  it  as  sanitized,  so  that  it  can  be  sunk  (as  sanitized)  by  any  con¬ 
sultant.  Note  that  ‘reclassification’  refers,  not  to  an  actual  class  binding 
being  changed,  but  a  (trusted)  entity  sinking  information  and  sourcing  it 
at  a  lower  class.  A  memorable  entity  of  class  sanitize  is  also  allowed  sink 
all  conflict  set  information,  but  in  doing  so  its  high  water  mark  rises  and  it 
becomes  inaccessible  to  the  consultants.  A 

Example  20  A  telephone  directory  holds  the  names  and  numbers  of  in¬ 
dividuals  from  a  number  of  different  departments.  The  information  about 
each  department  (telephone  numbers)  is  assigned  a  unique  class.  A  quan¬ 
tity  aggregation  policy  can  be  specified  which  states  that  no  user  is  allowed 
access  to  the  numbers  of  more  than  limit  departments. 

We  can  define  a  general  quantity  aggregation  policy  as 
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qty-agg{-.,_,_)  :  ( Vclasses  xKx  classes)  ■+*  72_s[c/asses] 

V  A  :  V classes-,  lim  :  N;  c  :  classes  •  lim  >  1  => 
qty-agg(A,  lim ,  c)  =  {A1  :  Vclasses\ 

A'  C  A  A  <  lim  •  A  U  {c}  *-+  r} 

Where,  give  a  set  of  classes  A ,  natural  number  N  and  a  class  c,  then 
qty-agg(A,  N,  c),  specifies  that  conglomerates  drawn  from  A,  not  larger  than 
N  may  flow  to  class  c.  Thus,  if  Depts  give  the  set  of  departments  and  user 
the  class  for  a  user,  then  policy  qty-agg(  Depts,  10,  user)  ensures  that  a  user 
may  not  discover  the  telephone  numbers  of  more  than  ten  departments. 

The  conflict  policy  in  a  Chinese  wall,  is  a  quantity  aggregation  policy 
where  a  consultant  may  only  read  one  (1)  dataset. 

A  high  water  mark  implementation  of  this  policy  will  keep  track  of  tele¬ 
phone  numbers  propagated  between  users  (using  the  system).  If  one  user 
accesses  accounting  and  personell  numbers,  then  this  is  reflected  in  his  high 
water  mark.  When  this  user  forwards  information  to  another  user,  these 
numbers  will  be  propagated  and  the  latter  user's  high  water  mark  will  re¬ 
flect  this. 

A  variation  on  this  policy  might  allocate  limits  based  on  the  clearance 
(classified,  secret,  etc)  of  the  user.  This  is  left  as  an  exercise  for  the  reader. 
A 

Example  21  The  granularity  of  aggregation  in  a  conglomerate  policy  ex¬ 
tends  to  to  information  classes,  not  entities.  Thus  if  we  wished  to  generalise 
the  last  example  to  the  traditional  telephone- book  example:  no  more  that 
limit  telephone  numbers  may  be  released  to  an  individual;  we  need  a  sepa¬ 
rate  class  for  each  number: 

|  Numbers  :  Vclasses 

The  policy  is  simply  qty-agg(Numbcrs,  limit, user).  Due  to  the  potential 
size  of  Numbers ,  it  would  not  be  realistic  to  directly  implement  such  a  pol¬ 
icy  using  our  high  water  mark  model.  But  the  high  water  mark  model  is  just 
one  possible  refinement  of  the  abstract  conglomerate  model.  We  could  pick 
a  restricted  class  of  policies  7lx[classes]  that  expressed  only  quantity  aggre¬ 
gation  policies  and  then  build  a  new  state  model  where  entities’  high  water 
marks  are  numbers  which  reflect  the  number  of  telephone  numbers  sunk  so 
far.  This  model  would  not  be  as  precise  as  the  group  confinement  model, 
since  when  one  user  forwards  information  to  another,  the  destination’s  high 
water  mark  must  be  updated  to  the  sum  of  the  source  high  water  marks. 
Precision  is  lost  because  they  may  share  some  telephone  numbers.  A 
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Example  22  A  large  corporation  is  divided  into  a  number  of  divisions,  and 
divisions  into  departments. 

)  Depts,  Divs  :  V classes 

It  is  possible  construct  a  conglomerate  policy  that  described  all  the  allowable 
flows  between  individual  departments  and  divisions  (and  their  conglomer¬ 
ates).  An  alternative  approach  is  to  use  military  style  classifications  to  asso¬ 
ciate  degrees  of  trustworthiness  with  employees  and  how  much  information 
they  are  allowed  access. 

A  classified  employee  is  only  allowed  access  to  information  about  at  most 
three  (3)  departments,  and  one  (1)  division: 

Class-Emp  =  qty-agg(Depts,  3.  classified)  LI 
qty-agg(Divs,  1,  classified) 

Note  that  there  is  no  constraint  on  what  departments  and/or  division  is 
accessed. 

A  secret  employee  is  permitted  access  to  at  most  six  (6)  departments 
and  two  (2)  divisions 

Sec-Emp  =  qty-agg{Depts,  6,  secret)  U  qty-agg{Divs,  2.  secret) 

A  top-secret  employee  is  permitted  access  to  all  departments  and  divi¬ 
sions 


Top-Emp  =  Divs  U  Depts  ~-  top-secret 

The  overall  corporate  security  policy  is  thus 

Corporate-Policy _ 

P  :  policies 

P  =  Class-Emp  LI  Sec-Emp  U  Top-EmpU 

Military 


Note  that  the  military  policy  is  still  enforced.  However,  suppose  the  classi¬ 
fied  user  has  accessed  three  departments,  and  the  secret  user  has  accessed  six 
other,  different,  departments,  then  the  classified  user  may  no  longer  forward 
information  to  the  secret  user.  A 
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In  all  of  these  examples  we  concerned  ourselves  with  what  information 
a  user  may  sink.  We  did  not  consider  what  information  users  may  source. 
For  example,  it  is  desirable  that  classified  users  from  example  22  should  be 
allowed  source  departmental  information.  Thus  we  could  redefine 

Class-Emp  =(qty-agg(Depts,  3,  classif  ied)U 
qty-agg(Divs,  1,  classif  ied))U 
U{d  :  Depts  •  Depts  U  classified  d } 

which  allows  a  classified  user  source  information  to  any  department.  Note 
that  we  cannot  express  any  aggregation  exceptions  on  how  many  different 
departments  classified  may  source  to:  our  framework  does  not  cater  for 
inconsistent  lower  bounds. 
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8  Implementing  Separation  Policies 

In  section  6  we  described  a  general  high  water  mark  model  that  could  enforce 
any  aggregation  policy  from  7£_s[dasses].  In  this  section  we  will  describe  an 
alternative  high  water  mark  model  that  can  enforce  any  conglomerate  policy. 
It  is  not  practical  to  implement  this  model  in  its  entirety,  and  therefore 
section  8.4  considers  useful  classes  of  separation  (and  aggregation)  policies 
that  have  reasonable  enforcement  mechanisms. 

8.1  Separation  Flow  Policies  Revisited 

A  separation  exception  in  a  flow  policy  extends  to  all  information  at  the 
classes  involved.  The  granularity  of  separation  of  duty  is  at  the  class  level, 
and  not  necessarily  at  the  entity  level.  For  example,  a  policy  might  state 
that  information  may  flow  from  class  lo  to  class  hi,  and  from  class  hi  to 
class  lo  only  in  the  presence  of  a  security  officer  so.  This  policy  might  be 
captured  as: 

P  ={lo,so)  hi 
{hi  ,so}  <-»  lo 

The  conglomerate  of  information  {hi, so},  may  flow  to  class  lo.  Suppose 
there  are  entities  H ,  L ,  and  SO,  representing  a  high  user,  a  low  user  and 
a  security  officer.  The  high  user  can  send  hi  information  to  the  security 
officer,  who  in  turn  forwards  it  to  the  low  user.  This  is  a  valid  flow  since  the 
information  that  the  low  user  sinks  is  a  conglomerate  (join)  of  hi  and  lo 
information.  Information  cannot  flow  directly  from  the  high  user  to  the  low 
user.  However,  the  low  user  can  now  be  thought  of  as  holding  conglomerate 
information  of  class  {lo,hi,so}.  which  can  be  combined  with  any  addi¬ 
tional  item  of  hi  information,  and  the  result  may  still  flow  to  lo.  Thus  the 
separation  exception  occurs  at  class  granularity,  not  entity  granularity. 

If  we  reexamine  the  requirements  of  this  downgrading  policy,  we  see  that 
the  desired  policy  is  not  a  separation  (flow)  policy,  but  a  reclassification 
policy.  A  security  officer  is  allowed  read  high  information  and  reclassify  it 
as  low.  This  can  be  captured  by  the  reflexive  relation 

Reclassify  =  {lo.sso}  hi  U  {hi}  sso  U  {sso}  lo 

Information  is  allowed  flow  from  high  to  sso,  and  from  sso  to  low,  but  not 
from  high  to  low.  Downgrading  (high  to  low)  can  occur  only  through  a 
memoryless  (partially  trusted)  security  officer. 
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Thus,  when  describing  a  separation  flow  policy,  one  must  remember  that 
the  separation  is  based  on  flows,  not  control.  In  the  example  above,  class  so 
represents  information  generated  by  the  security  officer,  not  control,  and  as 
information  it  (as  part  of  a  conglomerate)  could  propagate  through  (memo¬ 
rable)  entities.  We  will  consider  separation  as  control,  when  we  use  conglom¬ 
erate  relations  to  express  integrity  policies  in  section  11.  The  state  based 
security  mechanisms  will  be  built  with  this  in  mind. 

8.2  FMU:  A  Universal  High  Water  Model 

The  confinement  bindings  in  the  FMU  model  are  identical  to  the  bindings 
in  the  group  confinement  model,  except  that  instead  of  giving  a  set  of  limits 
(Pt,  )  on  the  classes  of  information  an  entity  may  sink,  we  give  a  set  of  sinks: 
the  information  classes  an  entity  may  sink. 

_  FM  U-conf-pol[  C ]  _ _ 

L  :  lattice[C } 

:  ents  -+-  C 
Zs,nk  ■  ents  ~  VC 

dom/3x  =  dom^.nt 
ran  C  dom  L 

0X-  €  £j,n k- 


Lattice  L  gives  the  flow  policy.  Every  entity  is  bound  to  a  component  of 
this  lattice  by  /3X,  which  represents  the  class  of  information  the  entity  may 
source.  Every  entity  is  also  bound  to  a  set  which  gives  the  set  of 
classes  of  information  that  the  entity  may  sink.  The  only  restriction  we 
place  on  these  bindings  is  that  every  entity  may  sink  the  class  of  informa¬ 
tion  it  sources.  The  difference  between  this  binding  and  group  confinement 
binding  is  illustrated  in  figure  6:  the  holes  represent  areas  where  separation 
exceptions  occur:  an  entity  may  not  sink  any  class  within  the  separation 
area,  however  as  soon  as  additional  classes  are  joined,  they  rise  out  of  the 
separation  area  and  the  flow  is  valid.  Aggregation  exceptions  occur  on  an 
entity  whenever  the  aggregate  (join)  of  two  classes  that  are  valid  sinks  of 
the  entity  leave  the  area  defined  by  The  area  between  1  (the  lower 
bound  of  L)  and  in  the  FMG  binding  represents  the  set  of  classes  that 
the  entity  may  sink.  Note  that  there  are  no  holes  in  this  area,  and  thus  no 
separation  exceptions  can  be  expressed.  Aggregation  exceptions  may  only 
occur  at  the  extremities  of  the  binding. 
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Figure  6:  Typical  FMU  and  FMG  bindings 

In  a  system,  flows  are  constrained  by  the  multilevel  security  requirement. 
Thus  a  secure  system  is  defined  as 

_  FMU-Secure-System[C] _ 

FMU-conf.pol[C] 

S  :  systems 

dom  0x  =  aS 
V  E  :  Vents ;  /  :  ents  • 

£-/€  5=> 

©  £  tsinkf 


A  system  is  considered  secure  if  for  every  conglomerate  flow  E  ►—  /  in  the 
system,  then  the  class  of  information  generated  by  conglomerate  E  (i.e.,  the 
lowest  upper  bound  of  the  class  of  information  each  e  G  E  may  source),  is 
allowed  to  be  sunk  by  /. 

We  can  map  any  conglomerate  policy  P  to  a  powerset  lattice  VcaP  by 

:  policies  —  (classes  Pclasses ) 
k  '■  policies  — +  ( classes  -+*  W classes) 

V  P  :  policies  • 

iP  =  {a  :  aP  •  a  >—  {a}} 

$,inkP  =  {a  :  aP  •  a  *-»  dom  P  >  {a}} 

This  mapping  is  flow  preserving  in  the  sense  that  for  P  :  policies 

V  AV classes;  b  :  classes  • 

A~  be  P  o  U$x<P(MD  €  *„•„*/>  b 
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Combining  this  with  the  FMU  model  gives  a  model  for  enforcing  conglom¬ 
erate  policies  as 


—  iFM  C-Secure-System _ 

FMC-conJ-pol 

FMU-Secure-System[V  classes] 

L  =  VCP 

P±-=  .Pi0- 

£>ink  —  —  $ tinkF  |  P — 


Since  $  is  flow  preserving,  it  follows  that  any  such  secure  iFMC  system  will 
be  a  secure  conglomerate  system,  i.e., 

V  iFM  C-Secure-System  • 

FMC-Secure-System 

8.3  iFMU:  A  State  Based  Refinement  of  FMU 

In  this  section  we  will  describe  a  high  water  mark  model  that  can  enforce 
arbitrary  conglomerate  flow  policies.  Section  8.3.1  views  a  system  as  a  collec¬ 
tion  of  entities  that  send  messages  to  each  other.  We  give  an  interpretation 
of  information  flow  for  such  a  system,  and  relate  it  to  the  abstract  notion  of 
information  flow  used  in  FM  U-Secure-System.  Given  this  view  of  a  system, 
section  8.3.2  proposes  a  high  water  mark  mechanism  for  enforcing  conglom¬ 
erate  policies.  Section  8.3.3  proves  that  any  system  that  is  secure  by  the 
high  water  mark  mechanism  will  be  secure  by  the  abstract  model  FMU.  Sec¬ 
tion  8.4  looks  at  restrictions  on  the  class  of  conglomerate  flow  policies  that 
result  in  simple  tests  and  operations  for  the  high  water  mark  mechanisms. 

8.3.1  System  Abstraction 

We  represent  a  system  as  a  collection  of  entities  with  an  ability  to  send 
messages  to  one  another.  Entities  represent  the  sources  and  sinks  of  infor¬ 
mation  in  this  system  for  example,  users,  files,  processes,  windows,  etc.  The 
state  of  a  system  represents  the  current  set  of  channels  between  entities, 
along  which  messages  are  being  sent.  We  will  assume  that  the  existence  of 
a  channel  represents  an  intention  to  use  it  to  send  and/or  receive  messages. 
The  set  of  possible  message  flows  between  entities  at  any  state  are  described 
by  a  conglomerate  relation  from  the  set 
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j  msg-flows  :  W[ents] 

We  will  describe  the  constraints  on  this  set  shortly.  Given  any  M  :  acc- flows, 
then  £7  < — ►  /  €  A/  is  interpreted  as  meaning  that  there  is  a  commitment 
for  information  flow  from  conglomerate  E  to  entity  /.  Thus  a  state  M  : 
acc-flows  cannot  express  any  aggregation  exceptions,  since  every  flow  is  a 
commitment  and  thus  there  is  no  opportunity  for  a  choice  between  one  flow 
or  another. 

There  are  two  types  of  entities,  memoryless  and  memorable 

memble, 
memless  :  Vents 

memble  H  memless  =  {} 

A  memorable  entity  is  any  entity  that  is  liable  to  source  any  information 
it  has  previously  sunk.  Examples  are  files,  variables,  untrusted  programs. 
An  untrusted  editor  is  memorable  since  it  may  contain  a  trojan  horse  that 
can  ‘remember’  any  secrets  it  edited.  A  memoryless  entity  will  not  inappro¬ 
priately  forward  information  it  sinks.  Trusted  routines  may  be  considered 
memorvless:  a  trusted  windowing  system  that  can  correctly  handle  multi¬ 
level  information  will  not  steal  a  secret  on  one  window  and  it  reappear  on  a 
classified  window.  An  appropriately  classified  user  is  prevented  from  cutting 
out  a  secret  from  one  window  and  pasting  it  to  a  classified  window:  in  this 
case  there  is  an  attempted  flow  from  a  secret  window  (entity)  through  a 
memorable  paste  buffer  (entity),  to  a  classified  window  (entity).  Of  course, 
the  user  could  read  the  contents  of  the  top-secret  window  and  retype  it  into 
the  classified  window.  However,  there  are  easier  ways  of  leaking  a  secret,  for 
example  using  a  telephone. 

When  a  message  is  sent  from  a  memorable  entity  e  to  entity  /  then  in 
addition  to  the  flow  from  e  to/,  there  is  a  potential  for  transitive  flows  from 
everything  that  sinks  to  e,  to /.  Thus,  if  M  :  msg-Jlows  represents  the  flows 
at  the  current  state  and  given  a  memorable  e,  suppose  {e,/}  •—  /  €  M 
and  {ff,e}  *-♦  e  €  M ;  then  { e,g,f }  > — ►  /  €  A/  should  also  hold;  however 
{g,f}  *“*  /  need  not  hold,  since  there  there  may  not  be  an  opportunity 
for  a  direct  flow  from  g  to  / — it  always  goes  through  entity  e.  Given  a 
memorable  entity  e,  and  current  message  flows  M  :  msg-flows,  the  set  of 
possible  conglomerates  it  can  forward  are  P  >  {e}.  Note  that  the  forwarding 
of  a  conglomerate  E  always  gets  performed  in  concert  vith  e  itself.  If  E  is 
a  set  of  memorable  entities,  then  the  set  of  conglomerates  it  could  forward 
is  the  set  all-fwd( M ,  E),  where 
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all  fwd(_,  _)  :  TZ[ents]  x  Vmemble  —  TVents 

V  M  :  7S[en<s];  E  :  Vmemble ;  e  :  memble  • 

all-fwd(A/,  {})={{}} 
all-fwd(A/,  E  U  {e})  = 

{ F ,  G  :  Vents\F  •-»  e  €  A/  A 
(7  €  all-fwd(A/,  £  -  {e})  • 
fuG} 

Memoryless  entities  are  assumed  not  to  propagate  information  in  this  way. 
Thus  we  can  define  the  set  of  valid  flow  relations  due  to  message  communi¬ 
cation  at  a  state  as 

msg-flou's  :  VR[ents] 

msg- flows  — 

{M  :  7£[en<s]| 

A/  €  V- Afrits ]  A 
V  E  :  Vents ;  /  :  ents  • 

E  <—  f  €  M  => 

(E  D  memless)  U  all-fwd(  A/.  E  D  memble )  ~  f  €  M} 

A  variation  of  the  all-fwd  function  gives  the  set  of  all  entities  that  can  be 
forwarded,  in  some  way,  by  a  conglomerate  relation  as 

all-fwd*( _ )  :  7v[cn/s)  x  Vents  —  Vents 

V  A/  :  7v[ents]:  E  :  Vents  • 

all-fwd* (A/.  E)  =  (Jdom(A/  t>  E) 

Note  that  all-fwd*(  A/.  E)  =  (Jall-fwd(  M,  E). 

If  our  system  makes  a  transition  from  a  state  with  flows  M  to  a  state  with 
flows  A/',  we  must  agree  with  what  the  overall  flows  should  be.  Clearly,  the 
flows  of  M  will  remain  in  effect  as  potential  flows  of  the  system.  However,  at 
state  A/',  memorable  entities  will  propagate  any  information  they  received 
during  A/  to  their  sinks  in  A/'.  Suppose  there  was  a  flow  {e,/}  *-.  /  £  A/, 
and  a  flow  {f,g}  «—  g  6  A/',  then  overall  there  is  also  a  flow  from  {e,f,g} 
to  g.  If  there  are  just  flows  {e,<?}  *-♦  g  and  {f,g}  *—  g  at  state  M  and 
an  only  flow  of  {g,h}  ■  h  at  state  A/',  then  since  *he  flows  represent  a 

flow  commitment,  then  we  can  can  say  that  there  is  a  flow  from  {e,f,g,h} 
to  h  overall,  but  not  necessarily  a  flow  from  {e,<?}  to  h  At  state  A/',  we 
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know  that  entity  g  holds  information  from  both  e  and  /,  and  it  is  this 
conglomerate  that  is  propagated,  not  the  individual  e  and  /. 

Thus,  if  a  system  has  made  a  series  of  transitions  that  result  in  overall 
flows  5  :  7 2[enZs],  and  enters  a  new  state  with  flows  M,  then  each  memorable 
entity  e  at  state  M  will  propagate  the  conglomerate  aU-fwd^S,  {e})  to  all 
its  sinks  in  M.  Therefore,  if  a  system  has  gone  through  a  sequence  of  states 
t  :  seqj  msg-flows ,  the  overall  flows  can  be  defined  as  flows  Z,  where 

flows_  :  seqj  msg-flows  — *  TV^ents] 

V  t  :  seq,  msq-flows ;  M  :  msg-flows  • 

flows  (M)  =  M  A 
flows  t‘{M)  = 
flows  ZU 

{E  :  Vents ;  /  :  enZsI.E  <—  /  €  A/  • 

( E  fl  memless)  U  all-fwd  *  (flows  t,  E  D  memble)  *—  /} 

Note  that  we  have  assumed  that  every  state  along  t  has  the  same  alphabet. 

If  a  system  is  described  by  a  prefix-closed  set  of  state  sequences  T .  then 
the  overall  flows  are  calculated  as  (Jflowsfl  J[). 

8.3.2  A  High  Water  Mark  Model 

We  are  now  in  a  position  to  describe  a  high  water  model  that  enforces  flow 
policies  from  the  FMU  model  for  systems  whose  flows  can  be  modelled  as 
abo%'e  (section  8.3.1). 

A  system  state  describes  the  current  message  flows  and  gives  the  policy 
binding  according  to  FMU-conf-pol. 

Secure-State[C] _ 

FMV-conf-pol[  C )  [t  Au„n  /dj.  ] 

M  :  msg-flows 

qM  =  dom  6 hum 

V  E  :  Vents-  f  :  ents  • 

E  -  /  e  m  => 

^  £s.n*/ 


Each  entity  e  has  a  current  high  water  mark  given  by  This  represents 

the  class  of  information  that  the  entity  currently  holds.  It  differs  slightly 
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from  the  high  water  mark  in  the  group  confinement  model  in  that  it  repre¬ 
sents  the  classes  of  information  the  entity  has  sunk  up  to,  but  not  including 
the  current  state.  Conglomerate  relation  M  represents  the  flows  due  to  the 
message  commitments  at  the  current  state.  If  there  is  a  flow  E  <-+  f  £  M 
then  the  class  of  information  generated  by  the  entities  in  E  must  be  sink- 
able  by  /,  i.e.  in  £„„*/.  Note  that  unlike  the  group  confinement  model,  we 
cannot  check  that  the  class  of  conglomerate  E  is  dominated  by  some  limit 
of  (tinkf,  since  £»,„*/  may  contain  holes  (recall  figure  6). 

The  initial  state  permits  any  flows  so  long  as  it  is  secure. 

P_  Initial- State[C] _ _ _ - 

Secure-State  [C] 


When  a  system  makes  a  transition  from  one  state  to  another  (as  a  re¬ 
sult  of  some  communication  requests),  only  high  water  marks  of  memorable 
entities  may  change.  The  high  w-ater  marks  may  rise  upwards  to  reflect  any 
new  information  a  memorable  entity  has  sunk.  A  secure  transition  is  defined 
as 


_  Secure-  TransfC] _ 

A Secure-State 

L'  =  L 

£*in  t-  =  £»"»*- 

V  e  :  ents  • 

t  £  memorable  Da M  => 

Kume  =  ©  <5/ium(lall'fwd*(  M.  {e})[) 
e  £  memless  fl  aM  => 

\wm€  =  A 


The  new  class  for  b\wme  is  a  member  of  since:  given  that  M  does  not 
contain  any  aggregation  exceptions,  then  we  have  that 

all-fwd*(M,  {e})  t-»  e  £  M 

and  since  M  is  secure  it  follows  that 

(]all-fwd*(A/,{e})[)  £  £„nie 

which  implies,  by  its  definition,  b'hu.me  £  £,,„*.  Note  that,  unlike  most  high 
water  mark  schemes,  a  high  water  mark  may  not  drift  upwards  arbitrarily. 
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it  rises  only  to  include  the  classes  of  information  it  has  sunk.  As  before,  a 
memoryless  entity  does  not  change  its  high  water  mark. 

A  system  is  characterised  by  a  single  initial  state;  a  state  transition 
function,  and  a  set  of  reachable  states.  The  system  is  secure  iff  the  basic 
security  theorem  holds. 

Theorem  2  A  system  is  secure  if  it  starts  from  a  valid  initial  state,  and 
if  every  state  transition  achievable  by  the  transition  function  is  a  secure 
transition.  Such  a  system  can  be  characterised  by 

_ iFMU-Secure-System[C] _ _ _ 

Initial- State[C] 

£  :  V Secure- Trans[C] 


□ 

Example  23  Consider  the  stock  market  database  example  11.  Table  3  gives 
the  flow  preserving  mapping  $  for  this  policy,  where  the  first  letter  of  each 
class  is  used  to  denote  the  class.  If  entities  U,  C.  and  5  represent  a  user. 


class 

4»xStock-Pol 

S’jintStOCk-pol 

user 

W 

{{u},{u,c},{u,c,s}} 

charge 

{c} 

{{c}} 

stock 

{s} 

{{s}} 

Table  3:  Flow  Preserving  Mapping  for  Stoek-Pol 


a  charges  file,  and  a  stocks  database,  then  <t>i  gives  the  initial  high  water 
mark  for  each  entity.  If  the  user  attempts  to  directly  access  the  database  5. 
then  there  is  a  flow  {5,  l'}  >—  V ,  which  is  invalid,  since 

^hu;m  S  U  hwm  F  —  {u  ,  s} 

£  £sint  L 

However,  if  the  user  first  reads  the  charges  file  (state  si),  he  may  then  read 
the  stock  information  (state  s?).  This  secure  history  is  outlined  in  table 
4.  Once  the  user  has  read  stock  information  his  high  water  mark  rises  to 
{u,c},  and  now  the  flow  {5,  U)  <->  V  €  Sj-M.  is  secure.  Note  that  the  user 
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state  s, 

s,.M 

{C}~  U 

W 

«2 

{5}  U 

{u.c} 

Table  4:  A  Secure  history  for  Stock  Access 

could  read  both  charges  and  stock  simultaneously  at  state  sj.  This  would 
be  modelled  as 


sj.M  =  {C,S}  —  U 

However,  we  would  require  some  assurance  that  the  program  that  allows 
the  user  access  the  database  does  not  provide  flow  {5}  U.  Compare  this 
state  with  a  state  with  flows  M  —  {C,  5}  U,  which  is  not  secure  since 
{$,  U}  ~  U  £  M.  A 

8.3.3  Formal  Basis  for  iFMU 

To  justify  that  an  iFMU  system  is  secure,  we  have  to  prove  that  it  is  a  re¬ 
finement  of  FMU-Secure-System.  Thus  we  need  to  construct  an  abstraction 
mapping  between  the  abstract  FMV  and  the  state  based  iFMU ,  and  prove 
that  a  system  secure  by  iFMU  will  also  be  secure  by  FMV. 

The  FMU  and  iFMU  share  the  same  set  of  entities.  In  the  iFMU  the 
initial  high  water  marks  of  entities  correspond  to  the  bindings  assigned  in 
FMU .  The  fact  that  high  water  marks  change  as  the  system  progresses  is 
a  artifact  of  the  implementation.  If  T  gives  the  set  of  all  possible  secure 
histories  of  a  system,  then  set  of  flows  over  the  entire  system  is  the  union 
of  the  flows  over  individual  secure  histories,  i.e.,  |Jflows(]T().  We  can  prove 
that  for  any  secure  history  t  of  the  system,  then 

V  E  :  Vents\  f  :  ents  • 

£'-•/€  flows  /  =>  ®  f>h  urn  (]£De  W 

which  implies  that  any  system  secure  by  iFMU  will  also  be  secure  by  FMU . 

8.4  A  Framework  of  High  Water  Mark  Models 

Recall  figure  6,  which  illustrated  the  shape  of  for  each  entity.  Not 
only  does  ( define  the  allowable  classes  of  information  that  an  entity 
may  sink,  it  also  defines  the  possible  classes  the  high  water  mark  may  rise 
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to.  Since  does  not  change  along  a  secure  history,  when  enforcing  a 
conglomerate  policy  P  :  policies,  it  is  sufficient  to  store  one  copy  of  P  a 
for  each  class  a,  and  have  cross  reference  this.  While  this  does  save 

considerably  on  space  (each  entity  has  a  current  high  watermark,  and  a 
class  from  aP  indexing  into  P  a),  the  structure  P  a,  has  a 

potential  to  be  quite  large.  Inspection  of  the  conditions  for  secure  states 
and  transitions  reveal  that  it  would  be  impractical  to  build  a  completely 
general  security  mechanism  to  enforce  an  arbitrary  conglomerate  policy.  We 
therefore  seek  classes  of  useful  conglomerate  policies  such  that  the  shape  of 
$  sink  result  in  simple  conditions  on  states  and  state  transitions.  We  can  also 
save  on  the  size  of  the  generated  lattice  policy,  if  desired,  by  using  Denning’s 
transformation. 

Sections  8.4.1  to  8.4.3  outline  how  effective  security  mechanisms  could 
be  arrived  at  for  reflexive,  aggregation  and  separation  policies. 

8.4.1  Reflexive  Flow  Policies 

If  a  flow  policy  P  is  reflexive  (i.e.,  a  member  of  Tlolclasses}) .  then  any  class 
a  €  aP  will  have  a  single  maximum  in  P  a  defined  as  <f>TP  a,  where 

4>t P  a  =  (Jdom  P  D>  {a} 

and  since  P  has  no  separation  exceptions,  the  area  in  has  no  holes, 

and  thus  £Jinit  can  be  represented  by  its  extremities.  If  l3e  gives  the  class  of 
entity  e  under  policy  P ,  then  its  initial  binding  is  calculated  as 

hum*  =  P  (13  e) 

£Te  =  $TP((3e) 

and  will  have  the  typical  shape  illustrated  in  figure  7.  Given  this,  the  con¬ 
ditions  on  secure  states  and  secure  transitions  simplify  considerably.  The 
condition  on  a  secure  state  that 

tum  me  Zstnkf 

must  hold  if  E  f  €  M ,  can  be  simplified  to 

U'Wmfl-E'D  Q  (jf 

Since  the  policy  does  not  express  any  aggregation  or  separation  exceptions, 
this  can  be  simplified  further,  so  that  state  flows  are  viewed  as  a  simple 
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Figure  7:  ( for  Reflexive  Policies 


relation  between  single  entities.  Thus  we  result  with  variation  of  the  interval 
confinement  model[10]. 

Note  again,  the  difference  between  the  notion  of  a  high  water  mark  in 
the  FMU,  and  a  high  water  mark  in  the  group  confinement  model:  in  FMG, 
6 hum  gives  the  (join  of  the)  class  of  all  information  that  has  been  sunk  by  a 
memorable  entity  upto,  and  including,  the  current  state;  in  FMU,  6 hum  gives 
the  (join  of  the)  class  of  all  information  that  has  been  sunk  by  a  memorable 
entity  upto,  but  excluding,  the  current  state.  Both  approaches  are  equally 
valid,  however  we  found  that  it  was  easier  to  use  the  latter  interpretation 
of  a  high  water  mark  when  developing  the  model  for  enforcing  separation 
policies. 


8.4.2  Aggregation  Flow  Policies 

If  the  flow  policy  does  not  contain  any  separation  exceptions,  i.e.,  P  £ 
[c/asses],  then  the  typical  shape  of  £„„*  is  as  pictured  in  figure  8.  Since 
there  are  no  holes,  then  can  be  represented  by  its  extremities.  Each 
entity  has  a  current  high  water  mark  and  a  set  of  limits  on  what  it  can 
sink,  (jj  (which  can  be  calculated  as  the  set  of  maximums  on  P).  As 
with  group  confinement,  the  high  water  mark  will  drift  towards  one  limit 
from  Zjttnk,  as  it  sinks  information. 

8.4.3  Continuous  Separation  Policies 

While  policies  from  5  [c/asses]  do  not  contain  any  aggregation  exceptions, 
the  shape  of  the  mapping  can  have  an  number  of  holes,  which  may 


Figure  8:  for  Aggregation  Policies 


make  implementation  mechanisms  impractical.  We  will  therefore  propose  a 
restricted  class  of  separation  policies  that  do  not  contain  any  holes,  so  that 
tainks  can  be  described  by  its  extremities. 

Define  the  set  of  continuous  separation  policies  to  be  72 _4„ [classes], 
where 


72_4.[A']  ==  {7?:72_4.[A]|VA.fl  :VX:  c  :  X  • 

{.4  -  c.B~  c}  C  R  A 
{c}  C  A  A  A  C.  B  => 

V  C  :  VX  •ACCaCCB=> 

Ch  c  e  R) 

Given  any  P  :  lZ-A.[classes ],  and  a  :  classes ,  then  the  extremities  of  the 
area  P  a)  -  {{a}}  can  be  given  by  the  mapping 

$.15  '•  [c/asses]  — >  classes  •+*  V classes 
$t  :  72_ 4, [c/asses]  — *  classes  classes 

V  P  :  72_4. [c/asses]  • 

$±SP  =  {a  :aP»a<->  mins  (dom(  P  t>  {a})  —  {{o}})} 

$t  P  =  {a  :  <*P  •  a  >-*  U(dom(P  C>  { o } ) ) } 

Given  this,  we  can  prove  that  for  any  P  :  72_4. [c/asses],  then 

V  A  :  V classes;  b  :  classes  •  A  /  {6}  => 

A  *->  6  e  P  o 
3  B  :  V classes  •  B  6  A 
5UAK$t 


Each  entity  will  have  a  current  high  water  mark  6hwm,  and  will  be 

represented  by  £xs  and  £t,  giving  the  lower  extremes  and  an  upper  extreme 
(there  are  no  aggregation  exceptions)  of  respectively.  This  binding  is 
pictured  in  figure  9.  We  know  that  a  flow  E  •— ♦  /  during  some  state  is  secure 


*  sinks 
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tim 


Figure  9:  for  Continuous  Separation  Policies 


only  if 

0<Wm(]-£'[)  €  Z„nkJ 
which  can  now  be  rewritten  as 

(©^AumflT’D  =  hu-mf)  V 
wm  0^1)  c  M  a 

3  B  :  Vclasses  •  B  €  £±,f  A  B  C  0 

Notice  how  the  high  water  mark  must  make  an  initial  ‘leap’  from  its  initial 
value  to  the  area  bounded  by  £j_s  and  This  is  how  a  separation  exception 
gets  enforced:  only  when  sufficient  classes  are  present  can  can  information 
flow  to  the  entity. 

A  similar  mapping  can  be  developed  for  continuous  separation  poli¬ 
cies  that  allow  aggregation  exceptions  (i.e.,  policies  from  7?_^.[c/osses]  U 
7 2_s [c/asses] .  Instead  of  a  single  top  on  there  are  a  number  of  tops. 

The  bindings  for  such  a  mapping  are  illustrated  in  figure  10 
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Figure  10:  £„•„*  for  Continuous  Separation-Aggregation  Policies 

9  Examples 

Example  24  The  stocks  database  example  11,  will  have  a  flow  preserving 
mapping  described  by  table  5.  and  a  lattice  policy  P^u.c.s}  (or,  Denning's 


class 

*±, 

user 

{«} 

{{u,c}} 

{u.c.s} 

charges 

{c} 

{c} 

{c} 

stock 

{*} 

{«} 

{8} 

Table  5:  Flow  Preserving  Mapping  for  Stock-Pol 

transformation  can  be  applied  to  the  components  given  in  table  5).  A 

Example  25  Separation  exceptions  can  be  used  to  prevent  classes  of  in¬ 
formation  being  made  available  until  such  time  as  it  is  appropriate.  For 
example  the  policy 

R  -  {re/}  b  U  {{re/,  a}  >—  6} 

does  not  allow  information  flow  from  class  a  to  class  b  unless  is  is  accompa¬ 
nied  by  ‘release’  information  of  class  re/.  Suppose  entities  R ,  A  and  B  are 
bound  to  re/,  a  and  6,  respectively.  Initially,  information  may  not  flow  from 
A  to  B.  However,  if  there  is  a  flow  from  R  to  A,  and  A  is  memorable,  then 
the  high  water  mark  of  A  rises  so  that  it  is  now  allowed  flow  to  B. 

This  can  be  used  in  the  Chinese  wall  example,  whereby  before  a  company 
‘goes  public1,  its  dataset  is  not  accessible  to  consultants.  By  combining  the 
dataset  with  release  information,  the  company  becomes  public. 


A  conflict  policy  will  give  entities  access  only  to  classes  that  have  been 
released: 


C-Rel-Pol _  :  conflict-set  — *  policies 
V  C  :  conflict-pol  • 

C-Rel-Pol  C  =  (J{c  :  C  «{c,  relc }  <— ►  cons 

{relc}  c} 

If  a  company  c  has  not  been  released,  its  high  water  mark  is  {c}  and  a  flow 
to  the  consultant  is  not  possible.  A  company  can  be  released  by  writing 
some  release  information  to  the  entity  holding  the  company  information. 
This  will  cause  the  high  watermark  of  the  company  entity  to  rise,  so  that  it 
forms  a  conglomerate  {c,  relc },  which  may  flow  to  consultant. 

Note  that  to  achieve  the  necessary  granularity  for  this  policy,  it  is  nec¬ 
essary  to  have  a  different  release  class  for  each  organisation  class.  If  we  had 
used  a  single  release  class  for  all  organisations,  then  it  could  propagate  from 
one  dataset  to  a  consultant,  giving  the  consultant  potential  access  to  all 
other  datasets.  A 

Example  26  Consider  a  downgrading  policy  for  the  Military  policy  from 
example  15.  We  could  use  a  reclassification  scheme  as  described  in  section8.1. 
However,  under  this  scheme  the  security  officer  is  not  accountable  for  what 
he  reads  and  downgrades.  A  more  satisfactory  scheme  would  be  to  use  a 
separation  of  duty  rule  which  required  the  admiral  to  release  information  to 
the  security  officer  for  downgrading.  The  security  officer  is  not  permitted 
arbitrary  access  to  secret  and  top-secret  information.  This  policy  can  be 
specified  as 

_ Mil-Downgrade _ 

P  :  policies 

P  =  Mil-2U 

{admiral}  so  U  {so}  classified 


The  admiral  can  read  top-secret  information,  reclassify  it  as  admiral  and 
forward  it  to  the  security  officer.  The  security  officer  can  take  this  informa¬ 
tion  and  reclassify  it  as  classified.  In  both  cases  some  trusted  (memoryless) 
entity  is  necessary  so  that  an  admiral  can  sink  a  secret  and  source  it  as 
admiral  (without  its  secret  component);  and  a  routine  to  allow  the  security 
officer  sink  admiral  information  and  source  it  as  so. 
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Now  we  have  separation  of  duty:  secrets  cannot  be  downgraded  without 
first  being  proposed  by  an  admiral,  and  then  cleared  by  a  security  officer. 
Note  how  the  separation  of  duty  is  achieved  by  the  use  of  memoryless  en¬ 
tities,  and  a  reflexive  policy:  no  separation  exceptions  are  in  effect.  This 
is  an  example  of  static  separation  of  duty,  where  the  separation  occurs  in 
a  predefined  sequence.  This  approach  is  similar  to  the  technique  in  [15]  for 
separation  of  duty  for  integrity  policies,  which  uses  partially  trusted  sub¬ 
jects  (memoryless  entities)  bound  to  pairs  of  classes  from  a  lattice  integrity 
policy  (implementing  a  reflexive  integrity  policy). 

In  section  11  we  will  give  an  example  of  a  dynamic  separation  of  duty 
integrity  policy.  A 
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10  Relating  Aggregation  and  Separation 

Separation  and  aggregation  exceptions  can,  in  a  sense,  be  thought  of  as 
duals  of  one  another.  An  aggregation  exception  might  state  that  A  may 
flow  to  c  and  B  may  flow  to  c,  but  together  they  may  not  flow  to  c;  a 
separation  exception  would  state  the  opposite:  together  they  may  flow  to 
c,  but  individually  they  may  not.  This  section  shows  how  this  relationship 
can  be  formally  established. 

We  can  prove  that,  given  any  aggregate  flow  policy  then  its  complement 
forms  a  separation  policy,  i.e., 

V P  :  7£_5[c/asses]  •  P  £  7J._x  [classes] 

For  example  an  aggregation  policy  that  includes  flows  {a}  c,  {6}  c,  but 
not  the  flow  {a,  6}  c,  when  complemented  will  allow  the  flow  {a.  b }  <— ►  c. 
but  not  the  flows  {a}  c  or  {6}  c. 

The  complement  of  a  separation  policy  however,  does  not  form  an  ag¬ 
gregation  policy.  For  example  a  policy  defined  by 

P  —  T{a,6,c}u{a}-^  b 

( b  is  disjoint)  is  a  separation  policy  (7l_A[classes]  includes  all  reflexive 
policies).  However,  P  includes  the  flow  {a.6.c}  •—  b.  but  not  the  flow 
{a,  6}  •—  6,  and  thus  P  is  not  an  aggregation  policy.  We  can  however, 
transform  any  continuous  separation  policy  into  a  reflexive  component  and 
a  separation  component,  and  the  complement  of  the  separation  component 
forms  an  aggregation  policy. 

A  continuous  separation  policy  P  :  TZ-A. [classes],  can  be  made  reflexive 
by  filling  in  the  'hole'  (area  where  separation  occurs)  to  give  a  policy  Pr 
defined  as 

Pr  =  {.4  :  Vclasses:  a  :  cla$$es\A  C  (Jdom  P  t>  {a}  •  A  U  {a}  ►—  a} 

This  new  policy  is  valid  and  reflexive  (Pr  6  7So[ classes]).  The  ‘hole’  that 
has  been  removed  can  be  put  into  a  new  policy  Ps  that  enforces  only  that 
hole  (i.e.,  the  separation  exceptions),  and  has  no  other  restrictions  on  flow  . 
It  is  defined  as 

Ps  =  -L aP  ~  (Pr  -  P) 
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and  forms  a  continuous  separation  policy  Ps  €  [c/asses].  Ps  can  also 
be  defined  as 


Ps  =  (±aP-  PR)U(±aPDP) 

=  PU(±aP-PR) 

=  P  U  TqP  U  (IqP  -  Pr) 

=  P^Pr 

and  since  a  sublattice  of  policies  with  the  same  alphabet  form  an  algebra, 
we  can  write 

Ps  LI  Pr  =  (P  n  Pr)U  Pr 

=  (PRuP)n(PRuP^ 

=  PuTqP 

=  P 

Thus  the  policy  P  can  be  thought  of  as  having  a  reflexive  component  Pr 
and  a  separation  component  Ps ■  We  can  prove  that  the  complement  of  the 
separation  component  of  P  forms  an  aggregation  policy,  i.e., 

V  P  :  7v_x„  [c/asses]  •  Ps  €  7v_$  [c/asses] 

Since  P  -  Pr  U  Ps-  we  have 

V.4  :  V classes:  b  :  classes  « 

A  —  b  €  P  o 

(A  -  6  6  Pr  A  A  -  b  €  PS) 

<=> 

V  :  V classes:  b  :  classes  * 

.4  i —  b  €  P  o 
/t  =  {b}  V 
(A  >-  b  £  Pr  A 
A  —  b  0  Ps) 

Thus  P  can  be  viewed  as  positively  enforcing  a  reflexive  component  t  Pol¬ 
and  negatively  enforcing  an  aggregation  policy  (Ps)-  We  can  view  this 
policy  in  terms  of  the  binding  pictures  of  section  8.4.  Information  may  flow 
from  class  conglomerate  A  to  class  b  iff  A  =  {h}  or,  A  falls  in  Pr  b 

(enforcing  the  reflexive  part  with  the  shape  of  figure  7).  and  if  A  does  not 
fall  in  k  Ps  b  (negatively  enforcing  the  aggregation  part,  which  has  the 
shape  in  figure  8).  Thus  the  shape  of  $>„„*  P  b  -  {{b}}  is  simply  the  shape 
of  k  Pr  b  minus  the  shape  P5  6,  which  turns  out  to  be  the  original 
shape  for  a  continuous  policy  described  in  figure  9. 
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11  Integrity  Policies 

A  well  known  dual  for  the  traditional  lntice  flow  model  is  the  Biba[4]  in¬ 
tegrity  model.  An  integrity  policy  describes  sets  of  clearances  and  a  lattice 
relation  between  these  clearances  that  defines  their  relative  superiority.  In 
this  section  we  will  illustrate  how  the  conglomerate  flow  model  can  be  used 
to  enforce  integrity  policies  described  as  conglomerate  relations. 

With  an  integrity  model  we  are  concerned  with  whether  or  not  one  entity 
may  affect  the  integrity  of  another.  We  will  use  the  same  conglomerate 
structure  to  model  a  system,  except  that  instead  of  information  flow,  we 
me  .el  integrity:  if  5  :  systems ,  then  E  f  E  S  means  that  the  entities  £ 
can,  as  a  conglomerate,  affect  in  some  wav  the  integrity  of  entitv  /. 

We  can  use  the  flow  policy  framework  to  describe  integrity  policies. 
Given  integrity  policy  P  :  policies ,  then  A  b  E  P.  means  that,  as  a 
conglomerate  A  has  higuer  clearance  than  b.  Each  entity  in  the  system  is 
assigned  a  single  integrity  clearance  using  the  function  0. 

a  integrity  secure  system  is  simply  a  system  such  that  for  every  ability  to 
change  integrity  E  >-*  f  E  S,  the  integrity  policy  must  be  upheld,  3(\E\)  *— 
0f  E  policies.  Thus  any  system  characterised  by  FMC-Secure-System ,  with 
the  integrity  interpretation,  is  a  secure  system. 

Example  27  A  cheque  may  only  be  written  to  by  an  accountant  and  a 
manager,  but  not  by  them  individually.  Thus  a  policy  for  writing  cheques 
is  the  separation  policy 


A 

We  can  use  the  conglomerate  high  water  mark  model  to  enforce  integrity 
policies.  However,  when  doing  so,  v  3  must  be  careful  about  the  propagation 
of  integrity  clearances  i.c .,  integrity  flow.  If  entity  A  can  change  the  integrity 
of  entity  B.  and  B  change  the  integrity  of  C,  should  the  integrity  clearance 
of  A  ‘flow’  to  Cl  In  the  Biba  model  this  is  not  an  issue  since  the  integrity- 
policy  is  transitive,  and  thus  it  is  implicit  that  A  can  affect  C.  However 
this  question  must  be  addressed  if  the  integrity  policy  is  non-transitive.  We 
can  model  entities  as  memorable  or  \  -noryless,  depending  on  whether  or 


not  they  propagate  integrity  changes:  affecting  the  integrity  of  a  memorable 
entity  has  a  potential  to  propagate  those  changes  to  everything  the  mem¬ 
orable  entity  can  affect;  affecting  the  integrity  of  a  memoryless  entity  will 
have  no  propagating  effect. 

Example  28  The  cheque  writing  policy  can  be  implemented  by  the  use  of 
cheque  transitions:  the  manager  writes  to  a  cheque  transaction,  and  then 
forwards  it  to  the  accountant  for  clearance  (or  vice  versa).  Only  when  the 
transaction  has  been  cleared  can  it  be  sent  to  the  cheques  file. 

Define  a  set  of  unique  labels  to  represent  each  cheque  transaction 

CT  :  V classes 

The  cheque  writing  integrity  policy  can  be  specified  as 

_ Cheque-Trans _ 

P  :  policies 

P  =  U{*  :  CT  •({mgr}  ^  t)  U  ({acc}  ^  ?)}u 
{mgr ,acc, t}  ■— > chk} 


To  propose  a  cheque,  a  manager  requests  a  transaction,  writes  to  it  and 
forwards  that  transaction  to  the  accountant,  who  in  turn  clears  it  and  send 
the  transaction  for  printing.  Note  that  an  accountant  is  not  permitted  to 
change  a  transaction  generated  by  the  manager  (and  vice-versa).  Compare 
this  dynamic  separation,  achieved  by  aggregation  exceptions,  with  the  static 
separation  in  example  26.  The  cheque  file  may  be  updated  only  in  the 
‘presence'  of  the  manager,  accountant  and  a  transaction.  We  can  prove  that 
this  policy  is  more  restrictive  that  the  original  cheque  policy,  i.e.. 

Cheque  C  Cheque-Trans 

Thus  the  original  separation  of  duty  rule  for  cheques  is  preserved  in  the  more 
detailed  policy. 

To  implement  this  policy,  all  entities  must  be  memoryless  except  the 
cheque  transactions,  which  should  be  memorable.  Transactions  are  used 
to  propagate  ‘clearances'  to  modify  other  entities.  The  cheques  file  must 
be  memoryless,  otherwise  once  the  first  transaction  has  been  written,  the 
clearance  for  writing  subsequent  transactions  will  be  retained,  regardless  of 
whether  they  are  cleared.  A  transaction,  class  t  will  have  an  initial  high 
water  mark  {<}.  It  is  not  dominated  by  class  chk.  If  a  manager  writes  to 
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a  transaction,  the  security  mechanisms  will  update  the  transaction  water 
mark  to  {mgr,<},  and  it  still  not  dominated  by  chk.  Now,  the  accountant 
may  examine  the  cheque  request  given  by  t.  The  accountant  is  not  however, 
allowed  modify  the  transaction — an  aggregation  exception.  If  the  cheque  is 
valid,  then  the  accountant  will  write  it  to  the  cheques  file,  (which  is  equiv¬ 
alent  to  a  conglomerate  write  of  accountant  plus  transaction  (transaction 
plus  manager)  to  cheques  file). 

Note  that  some  assurance  is  required  to  ensure  that  transactions  are  used 
only  once:  we  do  not  want  the  accountant  printing  multiple  copies  of  the 
same  cheque.  A 

In  this  last  example,  due  to  potential  siz*>  of  CT ,  it  would  not  be  practical 
to  directly  the  policy  as  a  powerset  lattice.  Like  the  telephone  book  example, 
some  other  mechanism  should  be  derived  which  implements  the  high  water 
mark  and  lattice  more  efficiently.  For  example,  every  cheque  transaction 
class  is  identical  in  terms  of  what  they  can  sink  and  source.  Therefore,  we 
could  build  a  lattice  with  classes  mgr,acc,chk  and  a  distinguished  class  t 
which  represents  any  transaction  class.  Whenever  a  t  occurs  in  a  water 
mark  it  is  instantiated  by  an  actual  transaction  identifier.  Further  research 
is  required  to  develop  refinements  of  the  high  water  mark  mechanisms  to 
make  use  of  similarities  in  pools  of  classes. 
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12  Discussion 


This  report  proposes  a  structure  that  can  be  used  to  describe  information 
flow  policies  that  may  have  transitivity,  aggregation  and  separation  excep¬ 
tions;  a  high  water  mark  mechanism  can  be  built  for  enforcing  these  policies. 

In  section  4  we  examined  how  conglomerate  relations  can  describe  flow 
policies  that  may  have  an  inconsistent  join  operator.  Having  inconsistent 
joins  in  a  flow  policy  provides  a  way  of  describing  aggregation  and  sep¬ 
aration  exceptions.  In  section  7  we  capture  many  popular  aggregation 
policies[6,19,20],  using  conglomerate  relations.  Research  on  separation  of 
duty  policies[7]  seems  to  have  concentrated  primarily  on  separation  rules  for 
integrity.  In  this  report  we  describe  separation  flow  policies,  and  give  some 
examples  of  how  they  might  be  used.  Conglomerate  flow  policies  are  state¬ 
less  specifications  of  security  in  a  system.  They  describe  the  different  classes 
of  information  that  can  exist  in  a  system,  and  how  they  may  propagate.  The 
granularity  of  a  flow  policy  extends  only  to  the  classes,  and  not  the  enti¬ 
ties  bound  to  those  classes.  This  must  be  remembered  when  specifying  flow 
policies,  in  particular,  separation  policies. 

Section  11  examined  how  conglomerate  relations  could  be  used  to  de¬ 
scribe  integrity  policies.  A  useful  policy  for  cheque  writing  was  described, 
which  contained  both  aggregation  (a  cheque  request  may  be  written  by  ei¬ 
ther  an  accountant  or  a  manager,  not  both),  and  separation  (a  cheque  may 
written  only  by  a  conglomerate  of  accountant  and  manager). 

Relations  and  operators  for  comparing,  composing  and  abstracting  con¬ 
glomerate  flow  policies  are  described  in  section  4.  These  operators  allow  us 
to  build  a  complex  policy  from  simple  components.  Section  7  gave  examples 
of  how  these  relations  and  operators  can  be  used.  Section  10  showed  how 
the  policy  complement  operator  relates  separation  and  aggregation  policies. 

In  this  report  we  only  considered  flow  policies  that  had  inconsistent 
upper  bounds  (joins).  A  more  general  class  of  flow  policies  is  one  that  in¬ 
cludes  policies  that  have  inconsistent  lower  bounds.  Such  policies  are  of 
type  V classes  «->  Vclasses,  where  a  maplet  X  >-+  Y  means  that  information 
may  flow  from  class  conglomerate  X  to  class  conglomerate  V .  Such  a  struc¬ 
ture  could  capture  policies  such  as:  mission-X  may  be  learnt  by  agent  A  or 
agent  5,  but  not  both.  Interesting  integrity  policies  can  be  described:  given 
classes  (purchase  order)  and  (cheque),  a  clerk  may  write  one  or  the  other 
but  not  both.  In  its  current  form,  our  high  water  mark  model  cannot  enforce 
such  policies.  Further  research  into  models  for  enforcing  such  policies  would 
be  worthwhile. 
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Sections  6  and  8  develop  high  water  marks  models  that  can  enforce 
conglomerate  flow  policies. 

The  first  model,  based  on  the  group  confinement  model[ll,12],  enforces 
aggregation  policies  (flow  policies  that  do  not  express  separation  exceptions). 
This  model  is  a  generalisation  of  the  traditional  high  water  mark  model. 
Each  entity  has  a  high  water  mark,  and  a  set  of  limits  to  which  it  allowed 
rise.  As  the  high  water  mark  rises,  some  of  the  limits  will  ‘disappear’.  This 
is  how  aggregation  exceptions  are  enforced.  This  model  enforces  conglomer¬ 
ate  policies  by  way  of  a  flow  preserving  mapping,  which  takes  an  arbitrary 
aggregation  policy,  and  maps  it  to  a  powerset  lattice  plus  high  water  marks 
and  limits,  to  be  enforced  by  the  high  water  mark  model. 

In  the  group  confinement  model,  we  identified  two  kinds  of  entities:  mem¬ 
orable  and  memoryless.  A  memorable  entity  will  propagate  any  information 
sunk  to  it.  A  memoryless  entity  does  not  propagate  information.  Thus,  only 
the  high  water  marks  of  memorable  entities  need  to  reflect  the  information 
they  have  sunk  to  date  (it  may  be  propagated).  Each  time  a  memoryless 
entity  sources  information,  its  class  is  the  (static)  class  of  the  entity.  Since 
the  high  water  mark  model  is  abstract,  there  are  no  restrictions  on  what 
entities  should  be.  They  represent  all  (interesting)  sources  and  sinks  of  in¬ 
formation.  Examples  are  users,  programs,  windows,  files,  or  even  persistent 
knowledge  environments[19].  If  an  entity  is  trusted  to  appropriately  handle 
information  at  some  class,  then  that  entity  can  be  considered  memoryless. 
For  example,  an  admiral  (example  15)  is  trusted  (by  the  very  nature  of  his 
binding)  to  handle  all  admiral  information  appropriately;  therefore  he  may 
be  treated  as  memoryless — he  is  allowed  read  some  secrets,  'forget'  them, 
and  then  talk  with  a  classified  user.  However,  if  he  creates  a  file  and  puts 
a  secret  in  it,  the  file  is  memorable  and  its  high  water  mark  must  reflect 
the  class  of  it  contents.  Trusted  software  can  be  thought  of  as  memoryless, 
a  certified  windowing  system  should  be  allowed  to  simultaneously  display 
secret  and  classified  windows  for  an  admiral. 

Sometimes  we  must  view  a  user  as  memorable.  For  example,  in  the 
Chinese  wall  policy,  consultants  must  be  considered  as  memorable — they  are 
liable  to  ‘remember’  information  about  conflicting  organisations.  If  a  user 
is  trusted  at  some  classes,  but  not  others,  it  may  be  necessary  to  model  the 
user  as  two  entities,  representing  the  memorable  part  and  the  memoryless 
part. 

We  discovered  that  the  group  confinement  model  generalises  many  ex¬ 
isting  flow  policy  models.  Figure  11  summarises  our  observations.  If  a  flow 
policy  is  quasi-ordered,  then  the  flow  preserving  mapping  from  conglomer- 
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Reflexive  Quoset 


confinement 

[3,10,15,21, 

22,25,26] 


Single,  static 
conf  inement 

[2,8] 


confinement 

[6,12,16,19] 


Figure  11:  Taxonomy  of  Policies  and  High  Water  Mark  Models 
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ate  policy  to  powerset  lattice  simplifies  to  the  Birkoff  mapping  from  quasi- 
ordered  set  to  powerset  lattice.  In  this  situation,  the  conglomerate  flow 
model  corresponds  to  the  traditional  lattice  flow  model  with  static  binding. 

If  the  flow'  policy  is  reflexive,  but  has  no  aggregation  exceptions,  then 
each  class  from  the  flow’  policy  maps  to  an  interval  pair  from  the  lattice  to  be 
enforced  by  the  high  water  mark  model.  Each  entity  is  bound  to  an  interval 
pair;  the  lower  bound  corresponds  to  the  initial  high  water  mark,  and  the 
upper  bound  gives  its  limit.  This  type  of  binding  for  memorable  entities 
corresponds  to  the  binding  used  in  the  Compartment  Mode  Workstation[26]. 
Thus  we  can  think  of  the  class  of  policy  enforced  by  this  system  as  reflexive. 
Memoryless  entities  bound  to  these  intervals  correspond  to  partially  trusted 
subjects[3,22],  and  thus  such  systems  can  also  be  thought  of  as  enforcing 
reflexive  flow  policies.  Recall  the  admiral  flow  policy  example  (15). 

The  second  high  water  mark  model  proposed  in  section  8  can  enforce 
any  conglomerate  flow  policy,  separation  and/or  aggregation.  The  model  is 
more  general  than  the  group  confinement  model,  in  the  way  it  models  the 
flows  in  a  system.  However,  its  notion  of,  and  mechanism  for  maintaining, 
high  water  marks  is  virtually  identical  to  the  group  confinement  model.  The 
only  difference  is  that  a  high  water  mark  of  a  memorable  entity  in  the  group 
confinement  model  represents  the  class  of  information  that  has  been  sunk 
to  that  entity  upto  and  including  the  current  state.  In  the  universal  high 
water  mark  model,  it  is  the  class  of  information  sunk  upto,  but  excluding 
the  current  state. 

While  the  universal  high  water  mark  model  can  enforce  any  conglomerate 
policy,  it  would  involve  an  unacceptable  overhead  to  maintain  the  water 
marks.  We  therefore  sought  a  smaller  class  of  policies,  continuous  separation 
policies,  that  could  be  enforced  efficiently.  With  these  policies,  a  high  water 
mark  must  make  an  initial  ‘leap’  before  it  can  rise  as  normal.  This  ‘leap’ 
corresponds  to  overcoming  a  separation  exception. 

In  any  system  that  uses  high  water  marks,  covert  channels  due  to  denial 
of  access  can  arise[9].  We  do  not  address  this  problem  in  our  high  water  mark 
model;  it  is  necessary  to  look  outside  the  model  to  detect  and/or  avoid  these 
flows.  Any  implementation  oriented  model  for  conglomerate  policies  should 
address  this  problem.  A  number  of  possible  strategies  are  considered  in  [11]. 

We  like  to  think  of  the  two  high  water  mark  models  as  providing  guide¬ 
lines  on  how  to  enforce  conglomerate  policies:  at  present  they  need  more 
refinement  to  be  used  in  practice.  It  would  be  worthwhile  to  develop  de¬ 
tailed  systems  oriented  models,  that  enforce  conglomerate  policies.  Only 
then  can  questions  on  denial  of  access,  what  constitutes  an  entity,  and  what 
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are  memorable  and  memoryless  entities,  be  effectively  dealt  with. 

Having  the  framework  of  conglomerate  flow  policies,  and  being  able  to 
consider  various  subsets  of  policies  is  appealing.  It  allows  us  to  make  com¬ 
parisons  between  the  policies  enforced  by  existing  models.  For  example,  we 
discovered  that  systems  with  partially  trusted  subjects  can  be  thought  of  as 
enforcing  reflexive  policies  (section7).  We  saw  how  reflexive  policies  provide 
a  form  of  static  separation  of  duty  (section  11).  Are  there  more  efficient 
mappings  and  mechanisms  for  restricted  classes  of  policy?  For  example, 
quantity  based  aggregation  policies?  An  interesting  application  of  this  abil¬ 
ity  would  be  to  investigate  if  the  reclassification  policy  described  in  [1]  can 
be  captured  as  a  conglomerate  policy. 
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A  A  Framework  of  Conglomerate  Relations 

Lemma  1  Conglomerate  abstraction  is  closed:  given  P  :  H[X]  and  C  :  VX , 
then  P@A  £  7£[Af],  i.e., 

V a  :  ((Jdom  P@C )  U  (ran  P@C )  •  fjdom  P  >  {a}  =  {c} 

PROOF  Abstraction  can  be  defined  as 
P@C=  KC%P  i>  C 

where  A'c  =  {A  :  VX  •  A  n  C  f)  aP  ^  A}. 

Consider  some  A  :  Vclasses,  a  :  classes  such  that  A  t—> >  a  £  P@C.  By 
the  definiton  of  range  restriction,  we  have  a  £  aP  n  C.  Furthermore,  since 
the  domain  of  A'c  is  drawn  from  subsets  of  aP  fl  C,  then  A  C  aP  n  C  also. 
Given  that  A  >—  a  £  P@C,  then  there  exists  some  A'  :  Vclasses  such  that 
A  t-*  A'  €  A'c  and  A'  a  G  P  E>  {a}.  But  since  P  is  a  valid  policy,  we 
know  that  a  £  A\  and  therefore,  since  a  £  aP  fl  C,  then  a  £  A  also.  Thus 
we  have 

V  A  :  Vclasses ;  a  :  classes  a=>a£A  (1) 

For  any  a  £  aP  n  C,  we  have  {a}  >—  a  £  P  and  {a}  ►—  {a}  £  Kc ■  This 
implies  that  {a}  •—  a  £  P&C.  This  with  the  fact  that  the  range  of  PTiC  is 
a  subset  of  aP  D  C,  and  the  range  is  drawn  from  subsets  of  aP  n  C,  implies 
that 


(Udom  P'SC)  U  ran  PSC  =  aP  n  C 

which  when  combined  with  equation  (1)  proves  the  lemma. 
COROLLARY  The  following  laws  follow 

q  PfiC  =  oPnC 

P'&aP  =  P 

P©{ }  =  {} 


□ 


Lemma  2  Given  conglomerate  relation  P  :  72[A'],  and  B ,  C  :  VX ,  then 
(P@B)@C  =  P@(Bn  C) 
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PROOF  Let 

A'c  =  {A  :  VX  •  A  n  aP  n  B  n  C  >->  A] 

Kb  =  {A  :  VX  •  A  DaPn  B  ~  A) 

We  have  by  defintion, 

(P@fl)@C  =  A'c  S  ( Kb  %  P  >  B)  >  C 

Distributing, 

( P@P  )'S  C  =  A'c  |  I<b  %  ( P  >  B )  >  C 

But  P  t>  B  t>  C  =  P  t>  Bf}C,  and  since  A’c  C  Kb,  then 

(P<SP)SC  =  Kc%P%BnC 
=  P4(£nC) 

□ 

Lemma  3  Conglomerate  abstraction  is  monotonic  with  respect  to  subset, 
i.e..  for  P,  Q  :  7v[A’j.  and  B  :  VX ,  then 

P  C  Q  =>  P4B  C  Q&P 

PROOF  The  monotonicity  of  range  restriction  gives. 

PCQ=>Pt>PCQt>fl 

if  A'e  =  {.4  :  VX  •  A  D  B  <—  A),  then 

P  C  Q  =>  I\b  9  P  t>  B  C  I\b  |  Q  t >  B 
=>  P4P  C  Q&B 

COROLLARY  Since  domain  restriction  is  monotonic  in  botli  arguments. 

BCCAPCQ=z>Pt>BC.Q  t>  C 

But  if  A’c  =  { A  :  VX  •  A  fl  C  >—  A },  then  Kb  C  Kc,  which  implies 

PC  Q  ABC  C  =>  KbiP  >  B  C  KclQ  >  C 
=>  P&BCQ&C 

□ 
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Lemma  4  Conglomerate  restrictiveness  is  a  partial  order. 

PROOF  Given  some  P,  Q  :  R[X ]  then  by  defintion, 

P  C  Q  qP  C  qQ  A  Q@aP  C  P 

•  Reflexivity  follows  since  Q@aQ  =  Q. 

•  (Antisymmetry)  The  Antisymmetry  of  subset  implies  that 

PQQaQQP^qP  =  qQ 

and  it  follows  that 

PCQ/\QCP=>PCQ/\QCP 
which  implies  P  =  Q. 

•  (Transitivity)  Transitivity  of  subset  gives 

PCQAQHR^aPCaR 

We  have,  by  the  monotonicitv  of  abstraction. 

QC  R  =>  MqQ  c  q 

=>  {R®aQ)<&aP  c  Q§aP 

But  aP  C  oQ  =>  P@aP  C  QQaP.  Furthermore.  P  C  Q  => 
Q&aP  C  P.  thus  we  have 

PQ  Q  R  =>  R&aP  C  P 
=>  PCR 

COROLLARY  If  the  operands  of  C  have  the  same  alphabet  then  con¬ 
glomerate  restriction  is  equivalent  to  superset.  □ 

Lemma  5  Conglomerate  abstraction  and  restriction  are  monotonic  with 
respect  to  each  other,  i.e.,  for  P,  Q  :  72[A']  and  5,  C  :  VX ,  then 

BCChPZQ^  P%B  C  Q®C 

PROOF  We  have  by  definition, 

B  C  C  aP  C  aQ  =>  aP  D  B  C  aQ  Pi  C 

=>  a(PSP)  C  o(g@C) 
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We  have 


PC  Q  => 


=> 


Q@aP  C  P 
( Q@aP)@B  C  P@B 
(Q@aP)@(fl  n  C)  C  P&B 
(Q@C)@{BDaP)  C  PSP 

p@p  c  g@c 


□ 

Lemma  6  Conglomerate  join  is  closed  over  72[A']:  given  P,  Q  :  72 [A'],  then 
P  U  (?  €  72[A’],  i.e., 

V  a  :  (U  dom  P  LI  Q )  U  ran  P  U  Q  •  f|  doni(  PuQ)  C>  { a }  =  { a } 

PROOF  Conglomerate  join  is  defined  as 

P  U  <5  =  {.4  :  PA',  a  :  A'|.4  U  {a}  C  qPuq(?  A 

(a  6  oP  ^  4HqP  i-  a  £  P)  A 
(a  £  aQ  =>  j 4  n  a  •—  a  £  Q)  • 

A  a) 

First,  it  follows  from  the  defintion  of  LI  that 

(J  dom  P  U  C?  U  ran  Pu  Q  C  qPUoQ  (2) 

Consider  any  a  6  qP  U  q<5-  If  a  £  oP.  then  we  know  {n}  >—  a  £  P.  and 
similarly  if  a  €  aQ.  then  {a}  *—  a  €  a(?.  Therfore  we  have 

Vo  :aPUa(Ji  {o}i-  o  £  PU  Q  (3) 

combining  this  with  equation  (2)  gives 

aPUaQ  =  (Jdom(P  U  Q)  U  ran{P  U  Q) 

Now  consider  any  A  h->  a  £  PuQ.  If  a  £  aP,  we  know  that  aPDA  a  G  P. 
But  since  P  is  valid,  then  a  £  A  fl  aP,  which  implies  that  a  £  A.  Similarly, 
if  a  £  o<?,  then  qQ  n  A  *—  a  €  <5.  and  a  £  A.  Therefore  we  have 

V  A  :  Vclasses:  a  :  classes  •  A  <~a£PuQ=>a£  A 

combining  this  with  equation  (2)  implies  that  P  LI  Q  is  also  valid. 
COROLLARY  The  alphabet  of  P  U  Q  is  qP  U  qQ.  □ 
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Lemma  7  Conglomerate  Join  gives  an  upper  bound,  i.e.,  for  P,  Q  :  P[A'], 
then 


PCPuQaQCPuQ 

PROOF  Since  a P  C  a(P  U  <2),  then 

PU  Q  C  {A  :  PA,  a  :  A|/lU{a}  C  aPuaQ  A 

a  £  aP  =>  A  PI  aP  *-*  a  £  P} 

If  Kp  =  {A  :  VX  •  A  fl  aP  *-»  A },  then  monotonicity  of  abstraction  gives 


P  U  <2©oP  C 
C 

C 

c 

c 


Kp  $  {A  :  PA',  a  :  A |.4  U  {a}  C  oPUqQa 

(fl  6  aP  ^  J  HaP  c  £  P )  •  .4  >—  a}  >  qP 
A’p  f  {  j4  :  P  A' ,  a  :  A'  |  .4  U  {  a  }  C  qPUqQ  A  a  £  aP  A 
(a  £  oP  ^  JflaPi-’  o  £  ?)  •  .4  t-  a } 

A>  £  {T  :  PA',  a  :  A'|A  U  {a}  C  aP  U  q<2  A  a  £  aP  A 
(.4  Cl  aP  *->  a  £  P)  •  .4  ►—  o} 

{.4  :  PA',  a:  A|AU  {a}  C  aP  A 
J<-.fl£PiJt-a} 

P 


The  symmetry  of  conglomerate  join  implies  <2  C  P  U  <2-  □ 

Lemma  8  Conglomerate  join  gives  the  lowest  upper  bound  of  its  argu¬ 
ments.  i.e..  for  P,  <2  :  7v[A'],  then 

V  R  :  7Z[X]  •PCPAQCP=>PuQCP 

PROOF  We  have  PCPaQCP=>qPuQCqP.  Next, 

PCP  =>  PS(qPUqQ)C  R(§(qPUq<2) 

=>  (M(qPUqQ))®qP  C  P 
V  A  :  V  X ;  a  :  A'  • 

A  i—  a  £  (PS(qP  UqQ))®oP  =>  A  »—  a  £  P 
=>  V.4  :  PA:  a  :  A  • 

A  >—  a  £  P@(qP  UqQ)  A  c  £  qP 

^J(lQPt--fl£P 


And  similarly  for  Q.  Thus  we  get. 


PCRaQQR  =>  VA:VX\  a:X  • 

(A  a  £  R<&(aP  U  aQ) A  a  £  aP 
=>  A  n  oP  —  a  £  P)  A 
(A  *->  a  E  R<(±(aP  U  aQ)  A  a  £  aQ 
=>  A  ft  aQ  *—  a  £  Q) 

=>  V  A  : VX ;  a  :  X  • 

A  *-»  a  £  R(Q(aP  U  aQ)  => 

(a  £  aP  =>  A  D  a  P  >—  a  £  P)  A 
(a£aQ=>Af)aQ<-^a£  Q) 

=>  V.4  :  VX  \  a  :  X  • 

A  <—  a  £  RQ(aP  U  aQ)  => 

A  ~  a  £  P  U  Q 
=>  Rii{aP  U  Q)  C  P  u  Q 
=>  PuQQ  R 

COROLLARY’  If  the  operands  of  U  have  the  same  alphabet  then  conglom¬ 
erate  join  is  equivalent  to  set  intersection.  □ 

Lemma  9  Conglomerate  Intersection  is  closed:  given  P.Q  :  7v[A’].  then 
PDQ£7Z{X}. 

PROOF  We  have 

Pn  Q  =  P<naPnaQ)U  Qk(aPnaQ) 

and  since  both  sides  of  the  U  are  valid  conglomerate  relations,  and  have  the 
same  alphabet,  then  P  n  Q  is  also  ■  alid. 

COROLLARY  The  alphabet  of  P  n  Q  is  qP  n  a  Q  □ 

Lemma  10  Conglomerate  Intersection  gives  a  lower  bound,  i.e.,  for  P.  Q 
TZ[X] 

PnQQpAPnQCQ 

PROOF  We  have  uPn  Q  C  o.P.  The  definition  of  n  implies  that  Pk(aPf) 
aQ  C.  P  n  Q.  which  implies  P  n  Q  C  P.  Symmetry  of  definition  implies 
PnQc  Q.  □ 
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Lemma  11  Conglomerate  Intersection  gives  the  greatest  lower  bound  of  its 
arguments,  i.e.,  for  P,  Q  :  Tl[X} 

V  R  :  U[  X]  •  RC  P  A  RC  Q  =>  RQ  Pn  Q 

PROOF  We  have  RCPARCQ=>aRCaPnQ,  and 

RCP  A  RCQ  =>  P@aP  U  Q@aR  C  R 

=>  P@(aP  n  qQ)@q/2  u  Q@(qP  fl  qQ)@qP  c  p 
Distribuiting  abstraction  throught  the  arguments  of  U  gives 

RCPARCQ  =>  (P@(aP  n  qQ)  U  Q@(acapaQ))&aR  C  R 
=>  PnQQaRCR 
=>  P  C  Pn  Q 

COROLLARY’  If  the  operands  of  H  have  the  same  alphabet  then  conglom¬ 
erate  intersection  is  equivalent  to  set  union.  □ 

Lemma  12  The  conglomerate  complement  operator  is  closed  over  the  set 
of  conglomerate^ relations  with  the  same  alphabet:  given  P  :  7v[A'].  then 
oP  =  aP  and  P  £  7v[A']. 

PROOF  Conglomerate  complement  is  defined  as 
P  =  T aP  U  (LoP  -  P) 

It  follows  directly  from  this  that 
o  P  -  U  dom  P  U  ran  P 
and  since  TaP  C  P,  then 

V  a  :  oP  •  {a}  ►—  a  £  P  (4) 

If  A  a  £  P,  then  we  know  that  A  <—  a  £  _LaP.  and  since  J_oP  is  a 
valid  policy,  then  a  £  A.  Combining  this  with  (4)  proves  that  P  is  a  valid 
relation. 

COROLLARY  the  alphabet  of  P  is  qP.  □ 

Lemma  13  The  conglomerate  operator  gives  the  complement  of  a  relation 
in  the  subset  of  7i[A']  of  relations  with  the  same  alphabet,  i.e..  for  P  :  72[A'] 

PuP  =  TaP 
PnP  =  ±Qp 

PROOF  follows  from  the  defintion  of  conglomerate  complement.  □ 
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Theorem  3  The  set  of  all  conglomerate  relations  form  a  lattice  with  order¬ 
ing  relation  C;  and  lowest  upper  and  greatest  lower  bound  operators  LI  and 
n,  respectively. 

COROLLARY  The  set  of  conglomerate  relations  with  the  same  alphabet 
forms  a  distributive  and  comlpementable  sublattice  of  72[A'].  □ 

Lemma  14  Conglomerate  Join  is  closed  over  the  set  of  the  set  of  conglom¬ 
erate  relations  that  do  not  express  separation  exceptions,  i.e., 

VP,C:ft_s[A'].PuQeft-s(A’] 

PROOF  We  have  by  definition  for  P ,  Q  :  7v[A'];  .4,  B  :  VX\  a  :  A’,  that 

A\J  B  >->  a  £  P  \J  Q  o  4  U  C  qPUoQ  A 

a£aP=>(Al)B)PiaP>~c£PA 
a£aQ=>(A\jB)C\aQ*~a£  Q 


But  since  P  £  7C_5 [A']  then 

(.4uB)noP^aeP 
=>  (4noP)u(flfloP)^fl6P 
=>  (AC\aP)>-~  a£PA(BC\aP)>—  a  £  P 

and  similarly,  since  Q  £  7C _ <? [ A' ] . 

\ 

(.lufljnoQ-oeQ 
=>  [  A  ncxQ)*—  a£Pf\(Br\aQ)>—  a£  Q 

Thus  if.4u/B> — ■  PuQ  then. 

a£QP^(AC\aP)>—  a£P  A 
o£qQ=>(  A  r\aQ)>—  a  £  Q 

which  implies  A  >—  a  £  P  LI  Q<  and  similarly  we  can  show  that  B  a  £ 
P  U  Q.  Therefore  P  U  Q  £  72_s[A').  □ 

Lemma  15  Conglomerate  join  is  closed  over  the  set  of  the  set  of  conglom¬ 
erate  relations  that  do  not  express  aggregation  exceptions,  i.e.. 

VP.Q:H-A[X)*PuQen-A[X] 
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PROOF  We  have  by  definition  for  P,  Q  :  72  [A'];  A,B  :  VX\  a  :  A',  that 

A  a  A  B  •->  a  => 

A  U  B  U  {a}  C  aP  U  aQ  A 
(a  £  aP  =>  .4  fl  aP  a  £  P)  A 

( a  £  aP  =>  B  tl  aP  >-*  a  £  P)  A 

(a  £  qQ  =>  A  H  aP  a  £  Q)  A 

(o  £  qQ  BHqPm  a  £  Q) 

and  since  P  £  TS-sfA'],  this  implies, 

a  £  aP  =>  {(A  fl  q P)  • — >  a,  (P  fl  aP)  ►-*  «}  C  P 
=>  a  £  aP  =>  (vt  U  B)  n  oP  *—  a  £  P 

Similarly,  since  Q  £  'll- a  [A’],  we  get 

a  £  qQ  =>  (A  U  B)  qQ  >—  a  £  Q 

combining  these  results  implies  AuJ5>-  a  £  Pu  Q.  which  impbes  P  LI  Q  £ 
71-a[X).  □ 

Lemma  16  Conglomerate  Join  is  closed  over  the  set  of  the  set  of  conglom¬ 
erate  relations  that  do  not  express  separation  nor  aggregation  exceptions, 
i.e.. 


VP.Q:fto[A']«  PLlQe  720[A] 

PROOF  Follows  from  the  results  of  the  last  two  lemmas,  since  if  P.Q  £ 
7vo[A'),  then  P  and  Q  are  members  of  both  7v_$[A']  and  [A*] .  and  so  is 

their  join.  But  we  have  that 

Tlo[X}  =  7l-A[X}r\7l-s[X} 

COROLLARY  By  inspection  we  see  that  our  definition  of  join  over  policies 
from  7lo[clas$e$]  is  identical  to  the  (reflexive)  policy  join  operator  defined 
in  [10].  D 
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B  Implementing  Aggregation  Policies 

B.l  FMG:  Group  Confinement  Model 

Lemma  17  If  P  is  a  flow  policy  with  no  separation  exceptions  then  the 
mapping  $  is  flow  preserving  in  the  sense  that  given  P  €  72-5 [c/asses],  then 

V  A  :  V classes',  a  :  classes  •  A  U  {a}  C  aP  => 

A  *—>  a  £  P 

3  B  :  V classes  »B  £  a  A  (J$j.P  Q,4[)  C  B 

Recall  that  the  definition  of  $  gives:  for  policy  P ,  and  a  :  classes ,  then 

4>j_P  a  =  {b  :  classes\(P)b  <  a) 

$tsP  a  =  maxs(dom  P  >  {a}) 

PROOF  (if  part)  Suppose  B  >-*  c  £  P  holds.  This  can  be  written  as 
(B  -  {6} )  U  {6}  ►—  c  £  P  for  any  b  £  B.  By  definition  we  have 

6  =  {o  :  c/asses|(P)a  <  b } 

which  implies,  by  definition  of  bound  (<),  that  for  any  a  £  $>j.  P  b.  then 

(B  -  {b})U  {b}  c  €  P  =>  (B  -  {b))\j  {a.  b)  r~  c  £  P 

and  we  can  progressively  add  components  of  $j.P  b  to  give 

(B-  {6})U{6}  -  c€  P=>  (B-  {6})U  {6}U$XP  b  ~  c  £  P 

and  we  can  repeat  the  process  for  every  other  conponent  of  P  —  {6}  to  finally 
give 

(B-  {6} )  U  {6}  -  c  6  P  =>  PuU0$iP  B\)~  c£  P 

But  since  bound  is  reflexive,  we  get 

B  -  {6} )  U  {&}  h~  c  £  P  =>  |J  $.1  F(jP[)  •—  c  £  P 

=>  G  dom  P  t>  {c} 

=>  3  C  :  Vclasses  • 

C  £  maxs  dom(P  t>  {c})  A  <J>j.P(JP[)  C  C 
=>  3  C  :  Vclasses  • 

Ce  $ t,  a  (j4>j.PQJ9[) c  c 
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PROOF  (only  if)  Suppose  that 

3  C  :  V  classes  • 

C  €  4»Tj  AU C 

Then  since  the  C  for  which  the  above  holds  is  a  member  of  we  have, 

3  C  :  V  classes  •  C  cA|J4>i(15[)£  ^ 

But  we  already  know  that  B  C  $j.P(]i?D  (  reflexivity  of  bound),  and  by 
transitivity  of  subseteq  gives  B  C  C.  Since  P  is  an  aggregation  policy,  then 
if  C  •—  c  €  P  then  all  subsets  of  C  may  flow  to  c.  Therfore  B  *—  c  6  P. 
and  the  lemma  is  proven.  □ 
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C  Implementing  Separation  Policies 

C.l  FMU:  A  Universal  High  Water  Mark  Model 

Lemma  18  The  mapping  $  is  flow  preserving,  in  the  sense  that  for  any 
policy  P  :  policies ,  then 

V  A  :  V classes-,  b  :  classes  • 

A  ~  b  €  P  kP  b 

PROOF  Given  A  :  Vclasses\  b  :  classes  the  defintion  of  $  gives 

U*xP(MM  =  -4 

$s,n kP  b  =  dom  P  >  {6} 

and  if  A  >—  b  6  P.  then  U^)J.^>(!-4[)  €  $iinkP  b  follows  and  vice-versa.  □ 

C.2  Formal  Basis  for  iFMU 

Lemma  19  Given  a  history  t  of  states  from  msg-flous.  and  a  state  M  : 
msg-flous.  then  for  every  memorable  entity  e  £  a.M 

all-fwd*( flows  t‘(M).{e})  = 
all-fwd*  (M  .{e})  H  memless IJ 
all-fwd* (flows  t,  all-fwd* (M .  {c  })  D  memble  ) 

PROOF  We  have  by  the  defintion  of  flows  t  and  all-fwd*.  that 

all-fwd*(flows  r(M).{e})  = 

[J  dom ( flows  /  >{e})U  (5) 

(J{£  :  Vents\E  •—  e  £  M  •  (6) 

( E  n  memless )  U  [J(  dom  flows  t  >  ( £  n  memble  ) )} 

Since  M  does  not  posses  any  aggregation  exceptions,  equation  (6)  can  be 
written  as 

[Jdom(M  >  {e})  fl  memless  U 

[J{ E  -.  Tents\E  £  dom  M  >  {e}  •  (^Jfdom  flows  t  >  (E  fl  memble))} 
=  ^Jdom(A/  >  {e})  fl  memless  U 

(Jdom(flowsf  Csd^domA/  >  {c} )  fl  memble )  (7) 
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But  e  is  memorable,  and  thus 

e  £  |Jdom(A/  t>  {e})  fl  memble 

which  implies  that  the  result  of  equation  (5)  is  a  subset  of  equation  (7),  and 
therefore  we  have 

|Jdom(flows  f(A/)  >  {e})  = 

(Jdom(A/  >  {e})  D  memlessl) 

(Jdom(flows  t  t>(|Jdom(A/  >  {e})  fl  memble)) 

and  the  lemma  follows.  □ 

Lemma  20  For  any  secure  history  t  (a  sequence  of  secure  states  formed  by 
a  series  of  secure  transitions),  and  a  secure  state  sn  such  that  f  (s„)  also 
forms  a  secure  history,  then  we  can  determine  the  high  water  mark  of  each 
memorable  entity  at  state  sn  in  terms  of  the  inital  high  water  marks  of  all 
the  sources  of  e,  i.e.. 

sn.bhu.me  =  0(5Aum(]all-fwd*( flows  /,{e})|) 

where  6hWm  =  t  lAuirT1 .  the  initial  high  water  marks,  and  the  defmtion  of 
flows  is  extended  to  sequences  of  secure  states. 

PROOF  We  will  use  induction  over  the  length  of  t. 

•  (base  case)  If  #t  =  1,  then 

all-fwd  *(flou's  t,  {e} )  =  al)-fwd*(  t  l.A/.{e}) 

and  since  the  transition  from  state  (t  1)  to  state  &2  is  secure,  we  have 
by  Secure- Transition. 

*2-hu mf  =  © A*um(jall-fwd*(flows  f,{e})|) 

and  the  lemma  holds  for  the  base  case. 

•  (inductive  hypothesis)  Suppose  that  the  lemma  holds  for  histories  of 
length  n.  Now  consider  a  history  r(sn.s„+i)  of  length  n  +  1.  By 
the  definition  of  a  secure  transition  from  s„  to  s„+i  we  have  for  a 
memorable  e, 

sn+\.bc  =  0s„.^u-mOall-fwd*(sn.A/,  {e} )[)  (8) 

=  0sn-^um(lall-fwd*(sn.A/,{e})n  memble  \)~  (9) 

0Sn^Aum(]all-fwd*(sn.A/,{6})n  memless[)  (10) 
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Since  the  high  water  marks  of  memoryless  entities  remain  static,  equa¬ 
tion  (9)  can  be  written  as 

0<5Au,m(]all-fwd*(sn.A/,{e})  PI  memble\)  (11) 

However,  the  high  water  marks  of  memorable  entities  change,  and 
applying  the  inductive  hypothesis  to  equation  (10)  implies  that  for 
any  memorable  /  €  all-fwd*(sn.A/,  {e}),  then 

$n  hwmf  =  ©  & kuiTTi  (]all-fwd*(flows  <,{/})[) 

and  therefore,  equation  (10)  can  be  written  as 

©{/  :  exits]}  6  all-fwd*(sn.A/,  {e}  )  n  memble  • 

0^Aum(]all-fwd*(flows  t,  {}})[)} 

=  0iAu,n(]aU-fwd*( flows  /, aU-fwd*(sn  .A/.  { e } ) n  memble)]) 

and  combining  this  equation  with  the  memoryless  case  gives 

+ 1  -bhu'm  f  = 

©  ^Aum(]all-fwd*(v«n.A/,  {e})  n  memless U 

all-fwd*(flows  <,all-fwd*(sn.A/,{e})n  memble)]) 

which,  by  replacing  all-fwd*  by  it  defintion  and  applying  the  result  of 
lemma  19  gives. 

Sn  +  \-hum€  =  ©  hum  Oall-fwd*  (flows  t'(sn).  {c}  )D 
i.e..  the  lemma  holds  for  histories  of  length  n  +  1. 

Thus  by  induction  the  lemma  is  proven. 

COROLLARY  Given  a  memorable  conglomerate  E  C  memble,  then 
©Sn^Au™ flT[)  =  ©  ^Aum(]all-fwd*( flows  t ,  E  )\) 

C 

Lemma  21  Given  any  non  empty  history  t  of  secure  states,  arrived  at  via 
a  series  of  secure  transitions,  then 

V  E  :  Vents :  / ents  • 

E  >—  /  €  flows  t  => 

©  <f’Au-m(]£'[)  €  htnkf 

PROOF  We  will  use  induction  on  the  length  of  the  history  t. 
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•  (base  case)  If  #t  =  1,  then  flows  t  =  (t  1).j4,  and  the  lemma  follows 
from  the  defintion  of  a  secure  state. 

•  (inductive  hypothesis)  Suppose  the  lemma  holds  for  histories  t  of 
length  n.  Consider  a  secure  history  t‘(sn+\)  of  length  n  +  1.  By  the 
defintion  of  function  flows.,  we  know  that  if  E  *—■  f  €  flows  t  (sn+i), 
then  either 

£'•-►/€  flows  t 

in  which  case,  by  the  inductive  hypothesis  the  lemma  holds;  or  if 
JET  t — ►  y  is  not  in  flows  t,  then 

E  <-*  /  €  {6  :  Vents;  f  :  ents\G  >—  /  6  sn+\.M  • 

(G  H  memless)  U  all-fwd*(flows  t,G  H  memble )  <—  /} 

Pick  a  G  :  Vents  such  that 

G  •—  /  £  s„+\.M 

and  G  propagates  E  to  /.  i.e.. 

E  =  ( G  (~l  memless)  U  all-fwd*(flows  (,  Cfl  memble  )  ( 12 ) 

Since  Sn+1  is  secure,  we  have 

®  +  i  (7[)  6  itrnk}  (13) 

(since  is  static,  we  have  =  s„+) )•  But  for  mem¬ 
orable  entities  in  G  can  be  calculated  according  to  lemma  20.  along 
with  the  fact  that  tku.m  is  unchanged  for  memoryless  entities  in  G. 
Thus  we  have. 

©sn+i-^um(]6’[)  =  0^um/J(Cn  memless) U 

all-fwd*(flows  (.Gfl  memble )[) 

applying  equation  (12)  to  this  result  gives 

©  •Sn  +  l-^u-mOG'p  =  ©‘Wmflfp 

But  this  result,  along  with  equation  (12)  (state  sn+]  is  secure)  implies 
that 

©  ^Au  m  0  £[)  €  (jnit/ 

i.e..  the  lemma  holds  for  any  secure  history  of  length  n  +  1. 

By  induction  the  lemma  holds  for  all  secure  histories.  □ 
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C.3  A  Framework  of  High  Water  Mark  Models 
C.3.1  Continuous  Separation  Policies 

Lemma  22  Given  a  continuous  separation  policy  P  :  72_  4..  [c/asses],  then 

Vj4  :  V classes-,  b  :  classes  •  A^{}f\A^{b}=> 

A  >—  b  £  P  o 

3  B  :  Vclasses  •  B  £  mins(dom(P  t>  {6})  -  {{},  {6}}))  A 
B  C  A  A 

A  C  P  >  {£} 

PROOF  Suppose  that  A  >—  b  and  A  ^  {}  and  A  ^  {6}.  It  follows  that 

A  C  |^Jdom(P  t>  {b})  (14) 

and  since  A  •—  b.  we  also  have 

A  £  (dom( P  t>  {6}))  -  {{}.{6}} 

thus  there  must  be  a  minimum  less  than  A.  i.e.. 

3  B  :  Vclasses  •  B  £  mins(dom(P  t>  { b } )  -  {{}.  {b}} ) 

combining  this  with  equation  (14)  gives  the  if  part  of  the  lemmma. 

If  we  have 

A  C  ijdom  P  0  { 6}  A 

3  B  :  Vclasses  •  B  £  mins(dom(  P  t>  {(>})-  { { } .  •{  A>} } ) 

then  since  P  is  non-aggregating,  we  have  for  C  :  Vclasses 

C  £  dom  P  >  {6}  €  P  A  C  €  dom  P  t>  {5}  €  P  => 
cuC^-ieP 

Which  implies  that  for  the  above, 

[Jdom(P  t>  {6})  ►—  b  £  P  (15) 

Also  given  our  inital  assumption,  we  have  some  minimum  B  :  Vclasses  such 
that  B  *->  6  £  P.  But  B  C  |Jdom(P  >  {6}),  and  P  is  continuous,  which 
implies  every  conglomerate  between  B  and  the  top  may  flow  to  6.  But  we 
have  B  C  A  and  A  C  (Jdom(P  t>  {6})  which  implies  that  A  —  6  £  P,  and 
the  lemma  is  proven.  D 
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D  Relating  Aggregation  and  Separation 

Lemma  23  The  complement  of  any  policy  not  exhibiting  separation  prop¬ 
erties  does  not  exhibit  aggregation  policies,  i.e., 

V  P  :  7v_s[c/asses]  •  P  €  71-a 

PROOF  By  definition  we  have 

P  =  TaPr\{±aP  -  P) 

Thus,  for  .4,5  :  Vclasses:  a  :  classes  then  {.4  <—  a.  B  <—  a}  C  P  implies 
that: 

•  If  {.4  ►—  o,B  h-'  o}  C  To5,  then  it  follows  that  .4  U  5  a  6  Tq5. 
and  thus  .4  U  5  •-*  a  £  P. 

•  If  .4  •—  a  E  ( laP  -  5),  then  we  have  A  •—  a  £  P.  But  policy 
P  €  H-,[classes],  and  thus  does  not  exhibit  any  separation  properties: 
if  A  a  g  P,  then  AilC  *—  a  §■  P  must  hold  for  any  C — if  a  C  existed 
such  that  A  U  C  •—  a  £  P  then  this  would  violate  the  requirement 

.4  U  C  •—  a  €  5  =>  .4 

Therefore  we  must  have  .4  U  5  i—  o  £  5  and  thus  A  U  5  •—  a  £ 
(±aP  -  P).  implying  that  A  U  5  •—  a  E  P-  By  symmetry,  if  5  a  G 
(IqP  -  5),  then  A  U  5  *—  a  £  P  also. 

Thus  we  have  for  any  P  £  lZ-s[cla$$es).  that 

V  ,4.  5  :  V classes:  a  :  classes  • 

{.4  h.  q,5i-  a)  C  P  => 

.4  U  5  ~  o  £  5 

i.e..  5  €  7J_^[c/flwes].  □ 

Lemma  24  Given  a  continuous  separation  policy  P  :  7v_^.(c/a«5e5],  then 
Pr  is  a  valid  policy,  where 

Pff  =  {A  :  Vclasses:  a  :  c/a5scs|>4  C  (J dom  P  t>  {a}  •  .4  U  {a}  •—  a 
PROOF  We  have 

o  P  =  (J  dom  Pr  U  ran  Pr 
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and  for  any  a  £  oP,  then  {a} 


a  £  S,  which  implies 


{a}~a€S*  (16) 

For  any  A  :  Vclasses ;  a  :  classes ,  we  have  A  >->  a  £  Pr  implies,  by  the 
definition  of  Pr,  that  a  £  A.  Combining  this  with  (16)  implies  that 

V  a  :  aP  •  p|  dom  St>{a}  =  {a} 

i.e.,  Pr  forms  a  valid  policy.  Note  also  that  qP  =  qPr. 

COROLLARY  Since  Ps  =  PPiPr,  and  Pr  is  a  valid  pohcy,  then  Ps  must 
also  be  a  valid  policy.  D 

Lemma  25  If  P  £  72-4. [c/asses],  then  Pr  £  TZo [clashes],  where  Pr  is 

defined  as  in  the  previous  lemma. 

PROOF  The  definiton  of  Pr  states  that  for  any  c.  then  all  subsets  of 
(Jdom  P  >(c)  may  flow  to  c.  Thus  if  A  U  B  may  flow  to  c.  then  so  too 
may  their  subsets,  i.e.,  A  *—  c  £  Pr  and  B  —  c  £  Pr. 

Similarly,  if  .4  may  flow  to  c  and  B  may  flow  to  c  then  both  .4  and  B 
are  subsets  of  (J  dom  P  t>  { c} ,  and  thus  so  too  is  .4  u  B  a  subset .  Therefore 
A  U  B  *—  c.  D 

Lemma  26  Given  a  continuous  separation  policy  P  :  11- A.[classes}.  then 

the  complement  of  its  separation  component  Ps  =  P  n  Pr.  where  Pr  is 
defined  as  above,  forms  an  aggregation  policy,  i.e..  Ps  £  TZ-s{classcs) 
PROOF  Since  a  sublattice  of  policies  with  the  same  alphabet  forms  a 
boolean  algebra,  and  q  P  =  a  Pr,  we  have 

Ps  =  P  n  Pr 

=  PuPr 

=  (ToPU  (iof  -  P ) )  n  Pr 
=  (Pr  n  TqP)  U  (Pr  n  (iof  -  P)) 

=  TaP  U(P«  n  loP  -  P) 

=  TaP  U  (  Pr  —  P) 

For  A,  B  :  P classes;  a  :  classes,  if  A  U  B  ►—  a  £  Ps.  then 

.4  US'—  a  £  TaP  V 
.4  US'— a  £  (Pr  -  P) 
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(17) 

(IS) 


If  equation  (17)  holds,  it  follows  that  {A  a,  B  *->  a}  C.  TaP,  which 
implies 

A>-+a£PsAB'—>a£Ps  (19) 

For  equation  (18)  we  have 

A*->aeP/i/\AuB~a$P  (20) 

Since  Pr  £  72<>[chisses],  then  A  U  B  *-+  a  £  Pr  implies  that  A  >->  a  £  Pr 
and  B  a  £  Pr.  Since  Pr  is  simply  policy  P  with  its  holes  filled  up,  then 
if  A  U  B  »-*  a  £  Pr,  then  there  must  be  some  conglomerate  C  containing 
both  A  and  5,  with  C  >->  a  £  P,  i.e. , 

3  C  :  V  classes  •AuBCCf\C<— a£P  (21) 

If  A  U  B  i—  a  g  P,  then  since  P  does  not  have  aggregation  properties,  we 
have 

A^a^PMBy-a^P  (22) 

Suppose  that  A  a  £  P  holds.  Then  by  equation  (21),  there  exists  some 
C  such  that  C  >—  a  and  A  U  B  C  C.  But  P  is  a  continuous  separation 
policy  which  implies  that  all  conglomerates  between  A  and  C  (including 
A  U  B)  may  flow  to  a,  i.e.,  A  U  B  ►—  a,  which  is  a  contradiction.  Therefore, 
ify4Uflt—  a  g  P  holds,  then 

A>—  agPAB*-~a#P 

combining  this  with  equation  (20)  gives 

A  t-t  a  £  (Pr  -  P)  A  B  *—  a  £  (Pr  -  P) 

and  thus, 

A>— a£PsAB>-~a£Ps 

combining  this  with  (19)  gives  the  desired  result.  □ 
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